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

Posted by Gustaf Neumann on
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.

Posted by Dave Bauer on

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.

Posted by Tom Jackson on

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.

Posted by Dave Bauer on
Tom, that's by design. See previous discussions on the forums.