openinteract-help

[Openinteract-help] NewUser question.

[Timothy M. A. <ti...@ad...>]

Hello (again!) list!

Sorry to be such a bother lately, but I think I'm finally getting the
handle on this thing. Please correct me if I'm wrong about how things
are working here.

In the site I'm working on (called Cornerstone), I'd like to have user
creation done only by the Superuser or Site Administrators. I've removed
the links in the templates to the /NewUser action, but you can still
type it in manually and create a user. I've also played around with the
"action.conf" file under my application's pkg/base_user-1.64/conf
directory, but I can't get the action to unmap. The impression I'm
getting from my RTFM action is that the application is defaulting to the
OpenInteract::Handler::NewUser.pm in my OI base directory after not
finding a Cornerstone::Handler::NewUser.pm in the action.perl files. Am
I off here?

And, what is the "correct" way to disable this (or any other)
functionality? I was thinking I could reimpliment the base_user package
without the functionality, but this seems overkill at this point. I
could also go into the NewUser.pm file in either my OI installation, or
the web app and fiddle with the actual perl code, possibly just having
it output nonesense code, but this seems to be kind of a kluge to me.
Ideally, I'd like the default "File Not Found" page to be displayed.

Any hints?

Thanks a ton!

/tma

Re: [Openinteract-help] NewUser question.

[Teemu A. <te...@io...>]

> I've removed
> the links in the templates to the /NewUser action, but you can still
> type it in manually and create a user.

You can disable /NewUser by removing the action in action.perl in base_user 
package, incrementing the version number (in this case, 1.65) in package.conf 
and reinstalling the package with oi_manage.

> OpenInteract::Handler::NewUser.pm in my OI base directory after not
> finding a Cornerstone::Handler::NewUser.pm in the action.perl files. Am
> I off here?

If your website is called Cornerstone, all OpenInteract::* will be mapped as 
Cornerstone::*, in this case, OpenInteract::Handler::NewUser -> 
Cornerstone::Handler::NewUser. So, if you want to create your own NewUser 
handler, create it with a different Handler name, for example 
OpenInteract::Handler::CreateUser or something, remove the NewUser action, 
add your own NewUser action and map it to *::CreateUser.

> And, what is the "correct" way to disable this (or any other)
> functionality? 

One thing I don't like about OI base packages is that they implement a lot of 
things that are tied with the core itself. It means that if you want to 
replace one of them, you have to exactly know what you are doing, i.e. if any 
stuff from a certain package you are going to replace is used in another one 
or in the core itself.

I worked around this by just disabling actions provided by some base_* 
packages I don't need or adding Handler security that blocks the use of 
certain features. Look into sys_security table to know how Handler security 
works. Basically, SPOPS objects that have security have a number in object_id 
field. Handlers have 0 (zero).

Example of SPOPS object with security:

(user 22 may only write the object):
sid: 39609
class: Example::SpopsObject
object_id: 5931
scope: u
scope_id: 22
security_level: 8

Example of a Handler (action) with security:

(No one - world - may execute the handler NewUser):
sid: 39610
class: Example::Handler::NewUser
object_id: 0
scope: w
scope_id: world
security_level: 1

For handlers to use security, the action.perl must not contain security => no 
for the action.

More info:
http://www.openinteract.org/docs/security.shtml

It is easier to use the base_user package because it has all the 
authentication stuff with the sys_user table etc. implemented. base_group has 
a group system implemented, which is tied with the Handler security itself. 
Pretty hairy stuff if you want to heavily modify the functionality without 
getting into modifying the base_* packages themselves (something you don't 
want to do or you have to maintain and sync the changes in the package as new 
versions of OpenInteract appear).

Just go with the base_* packages and be creative: add a new package, something 
like cornerstone_user and cornerstone_group that have additional features you 
want (a new user manager, registration application, password changing etc) 
and possibly add more fields for users. I for example used an additional 
table for additional personal user information and linked it with sys_user 
table. 

We have heavily modified the OpenInteract system and replaced most of the 
essential actions provided by base_* packages with more robust alternatives 
in our Dicole project. You might find it interesting and maybe even useful 
for your project. It is an extension to OpenInteract and acts as a more 
abstract layer for creating web based applications:

http://www.dicole.fi/docs/dicole_api_overview.html
http://www.dicole.fi/docs/introduction.html

Currently in development but first version of a groupware created with it will 
be available in August.

-- 
--------------

Teemu Arina

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
http://www.dicole.fi

"Discover, collaborate, learn."

Re: [Openinteract-help] NewUser question.

[Timothy M. A. <ti...@ad...>]

On Fri, 2004-05-28 at 02:04, Teemu Arina wrote:
> > I've removed
> > the links in the templates to the /NewUser action, but you can still
> > type it in manually and create a user.
> 
> You can disable /NewUser by removing the action in action.perl in base_user 
> package, incrementing the version number (in this case, 1.65) in package.conf 
> and reinstalling the package with oi_manage.
> 
Ahh... I didn't increment the version number. This could bring up
possible conflicts, I believe. One of the projects I'm doing this for is
going to be a shopping cart, so I'd like people on that site to be able
to create their own users, but the administration site I'd like locked
down. The NewUser functionality would work perfectly in the former,
while it's not good in the latter.

If I understand the versioning correctly, this isn't possible with the
same OI base path. So, I'd have to have multiple installations of the OI
framework on my development box. Not necessarily a problem, but I can
see myself struggling on a problem for an hour or so, only to find out
that I'm mucking about the wrong OI base.

> > OpenInteract::Handler::NewUser.pm in my OI base directory after not
> > finding a Cornerstone::Handler::NewUser.pm in the action.perl files. Am
> > I off here?
> 
> If your website is called Cornerstone, all OpenInteract::* will be mapped as 
> Cornerstone::*, in this case, OpenInteract::Handler::NewUser -> 
> Cornerstone::Handler::NewUser. So, if you want to create your own NewUser 
> handler, create it with a different Handler name, for example 
> OpenInteract::Handler::CreateUser or something, remove the NewUser action, 
> add your own NewUser action and map it to *::CreateUser.

Ok, here's what I didn't understand. I removed all traces of the
NewUser.pm from my application; at least all that 
 find . -type f -exec grep -il newuser {} \;
reported. I then restarted Apache, and the NewUser form was still there.
This was why I was (incorrectly, it seems) supposing that we defaulted
back to the OI base directory.

So, to eliminate the functionality, I should just leave the base_user
package alone, create a new package like Cornerstone::Handler::NewUser,
map that package to the /NewUser URL, and have it do something
completely different like displaying a new user introduction or
something?

> > And, what is the "correct" way to disable this (or any other)
> > functionality? 
> 
[SNIP]
> I worked around this by just disabling actions provided by some base_* 
> packages I don't need or adding Handler security that blocks the use of 
> certain features. Look into sys_security table to know how Handler security 
> works. Basically, SPOPS objects that have security have a number in object_id 
> field. Handlers have 0 (zero).
[SNIP]
> Example of a Handler (action) with security:
> 
> (No one - world - may execute the handler NewUser):
> sid: 39610
> class: Example::Handler::NewUser
> object_id: 0
> scope: w
> scope_id: world
> security_level: 1
> 
> For handlers to use security, the action.perl must not contain security => no 
> for the action.

Ok, currently there is no Cornerstone::Handler::NewUser in the
sys_security table. So, I can add it and tweak the security to disallow
access. Not the most elegant solution, but it should work.

[SNIP]

> We have heavily modified the OpenInteract system and replaced most of the 
> essential actions provided by base_* packages with more robust alternatives 
> in our Dicole project. You might find it interesting and maybe even useful 
> for your project. ...
[SNIP]

I really do like the CSS integration, which is something I was going to
try to do on my application. How much is this going to muddy the waters
for me? As you've no doubt discovered by now, I'm having a bit of
trouble navigating the learning curve. I'm worried that I'll have
trouble discerning Dicole issues from OI issues until I've grokked OI a
little better.

> http://www.dicole.fi/docs/dicole_api_overview.html
> http://www.dicole.fi/docs/introduction.html
> 
> Currently in development but first version of a groupware created with it will 
> be available in August.

Does this mean that Dicole will be production in August, or the
groupware will be?

Thanks again for the patience. Everybody has been quite illuminating
with the replies.

/tma

Re: [Openinteract-help] NewUser question.

[Timothy M. A. <ti...@ad...>]

On Thu, 2004-05-27 at 22:21, Timothy M. Adamec wrote:
> Hello (again!) list!
> 
> Sorry to be such a bother lately, but I think I'm finally getting the
> handle on this thing. Please correct me if I'm wrong about how things
> are working here.
> 
> In the site I'm working on (called Cornerstone), I'd like to have user
> creation done only by the Superuser or Site Administrators. I've removed
> the links in the templates to the /NewUser action, but you can still
> type it in manually and create a user...
[SNIP]
Replying to my own message... Shouldn't that be illegal? :) At any
rate...

After much reading of code and documentation and breaking of code, not
to mention some sleep, I think I'm finally getting the hang of this. My
boss also mentioned to me today that we're going to need
internationalization. Looks like it's OI2 for me, then.

For some reason OI2 seems to fit my mind better than OI did; perhaps
it's because the tutorial was excellent.

As for the problem with disabling the /NewUser creation I was playing
with under OI, all I had to do was move the new_user* templates under
$site/pkg/base_user/templates and I got the "File not Found" message I
was looking for originally.

Thanks again to everybody (especially Chris and Teemu) for the help.

/tma

Re: [Openinteract-help] NewUser question.

[Chris W. <ch...@cw...>]

On May 28, 2004, at 11:53 PM, Timothy M. Adamec wrote:
> After much reading of code and documentation and breaking of code, not
> to mention some sleep, I think I'm finally getting the hang of this. My
> boss also mentioned to me today that we're going to need
> internationalization. Looks like it's OI2 for me, then.
>
> For some reason OI2 seems to fit my mind better than OI did; perhaps
> it's because the tutorial was excellent.

OI2 has much better documentation and has learned from many of the 
mistakes in OI 1.x. I think it should be more straightforward to pick 
up for new folks as well, particularly because the deployment is 
easier. While things are still changing they shouldn't change too much 
before 2.0.

> As for the problem with disabling the /NewUser creation I was playing
> with under OI, all I had to do was move the new_user* templates under
> $site/pkg/base_user/templates and I got the "File not Found" message I
> was looking for originally.

In OI2 you can disable an action by setting the action property:

url_none = yes

which means the action will not respond to any URLs. (You can still 
look it up by name though.)

You can do this in a global configuration file as well so it will be 
preserved among your package upgrades -- a look at 
OpenInteract2::Config::GlobalOverride may provide some help.

Good luck!

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988