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.

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.

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.