Forum OpenACS Development: Support no_login on xo::cc::permission

Collapse
1: Support no_login on xo::cc::permission
Posted by Dave Bauer on 09/23/08 04:24 PM
Can we support a no-login flag on xo::cc::permission similar to permission::permission_p ?

This would make xowiki more friendly. Right now if you session expires, you have to login to view an xowiki page, as the xowiki check_permission procedure calls xo::cc::permission which requires login. This means even though check_permission procedure claims to not force login, the login is still required.

This would make the xo::cc::permission procedures work like the openacs procedures and prevent confusion. Xowiki then would have a consistent UI, offering edit links when a user was logged in, but their session expired, then requiring a login to refresh the session when and edit action is attempted.

Collapse
2: Re: Support no_login on xo::cc::permission (response to 1)
Posted by Gustaf Neumann on 09/23/08 06:16 PM
Since a while (about 8 months ago), the permission procs of the connection context (xo::cc) use "permission::permission_p -nologin", but the ::xowiki::Package uses "force_refresh_login true". So, when the package is initialized, it asks for the login to confirm the user_id.

If i remember correctly, the reason for doing this was to circumvent cases, where an auth::require_login caused problems, if executed under a catch. By forcing the refresh early, this does not happen.

i'll turn off force_refresh on one of my installations to give a more detailed analysis. Maybe, we can add a package parameter to force logins or not. The current behavior has it advantages as well: it provides a consistent user-interface, no matter whether the login expired or not. if the login is not forced, some controls (wiki menu, edit buttons etc.) will suddenly disappear, when the login expires, and the user has to login manually again.

Collapse
3: Re: Support no_login on xo::cc::permission (response to 1)
Posted by Dave Bauer on 09/23/08 06:24 PM
Ok, this is just a xotcl/xowiki problem correct? All other packages can support -no_login to generate links without a problem as far as I know.
Collapse
4: Re: Support no_login on xo::cc::permission (response to 3)
Posted by Gustaf Neumann on 09/23/08 07:22 PM
every package, that does a catch around code which can run into an auth::require login has the same problem.

Generating links is not the problem. The question is, if some code wants to refresh a login, where can can it do this safely. This is an issue when content from various packages is included....

Forcing an early refresh, as xowiki does it now, is a simple and safe solution. maybe, one can write a more clever catch-and-throw to handle this case.

Collapse
5: Re: Support no_login on xo::cc::permission (response to 4)
Posted by Dave Bauer on 09/23/08 07:31 PM
Ah,

Most regular packages just call auth::require_login at the top of the tcl script if they want to require a login, depending on what sort of page it is.

Generally anything that requires read permission does not force a login, and anything that requires write, create, admin etc forces a login.

It's just execpected to be forced to login to read a page that is available to the public even if your session has expired.

Collapse
6: Re: Support no_login on xo::cc::permission (response to 5)
Posted by Tom Jackson on 09/24/08 07:02 AM
Dave,

For a very long time I have had problems with cookies and sessions.

The problem I have run into is that OpenACS uses several cookies when there should only be one session cookie.

The session cookie should be opaque, which means in this context that if you capture the session key you don't know anything else. The user_id, user state, etc. associated with the session is maintained on the server.

Some (maybe all?) versions of OpenACS encode the user_id in a cookie. The result is that some pages mislead the user and make it appear that the user is logged in, even after a session has expired. For OpenACS this is more important than for most applications.

The solution is to use only one cookie which contains only a session key.

Collapse
7: Re: Support no_login on xo::cc::permission (response to 6)
Posted by Dave Bauer on 09/24/08 02:52 PM
Tom, that's by design. See previous discussions on the forums.