Hi Wes,
In fact I already do 1) as you propose. Mainly to remember proper
redirects after login and similarly for flash messages etc.
Here's my issue:
In my environment.rb for Radiant I have,
config.action_controller.session = {
:key => '_appname_cms_session',
:secret => 'mysecret'
}
This is where Radiant stores it's session for things like admin-side
logins. And the cookie path is set for "/", but shouldn't it be for "/
admin" by default ??? I think sending admin-side cookie to all Radiant
requests is a bad idea and should be limited to "/admin" path.
But I digress...
My custom auth system uses authlogic, which creates it's own cookie as
subscriber_credentials when user successfully logs in (since its
authlogic default naming convention in form of modelname_credentials).
However the two auth-sessions are actually linked to a single session,
since deleting the subscriber_credentials cookie in the browser has no
effect and it gets recreated next time you refresh a page that
requires a logged in user.
Whereas deleting the Radiant cookie _appname_cms_session, I get logged
out (from both admin and custom auth or from either depending where I
had sessions open).
The issue, of course, that there is only one true session that gets
initialized and if I destroy it I get logged out from both admin and
custom auth side.
On Oct 6, 9:38 am, Wes Gamble <[email protected]> wrote:
> Hmmm...
>
> Some thoughts:
>
> 1) You could maintain multiple independent sessions logically by simply
> establishing some naming convention of session key values in the one
> session. All admin session keys are session[:admin_xxx] and all
> "regular" session keys are session[:regular_xxx]. You could enforce
> this fairly easily with a couple of wrapper functions and the discipline
> to never access the session directly.
>
> 2) You could also embed one "session" inside the standard session object
> by simply establishing a session key of "inner_session" (or
> "admin_session" or whatever). This would likely require you to decide
> which session the top-level keys represented and which the "inner" key
> was responsible for. Same as #1, just not flat.
>
> 3) You could maintain a Session AR object independent of the "session"
> object. Similarly, if you were using cookie based sessions, you could
> always just maintain a completely separate cookie that you manage by hand.
>
> 4) You could always force a logout from one auth. system when the user
> logs in to the other, assuming that both logins don't need to be active
> at the same time.
>
> W
>
> On 10/6/10 10:26 AM, swartz wrote:
>
> > Hi Wes,
>
> > Yeap pretty much.
>
> > On Oct 5, 6:36 pm, Wes Gamble<[email protected]> wrote:
> >> So you need to maintain two distinct sessions from one browser? Is
> >> that right?
>
> >> W
>
> >> On 10/5/10 6:22 PM, swartz wrote:
>
> >>> I have a 0.9.1-based radiant install that uses a custom end-user auth-
> >>> system. It uses authlogic and based primarily on examples from reader
> >>> and members extension.
> >>> I've switched from the default cookie session store
> >>> to :active_record_store for storing session information.
> >>> And I've also ran into a problem. Both radiant admin and my custom
> >>> auth system end up sharing session. Specifically, if I have a user
> >>> that logs into Radiant admin AND into the custom auth system to view
> >>> content, the session gets messy. Thing sometimes get REALLY messy
> >>> (wrong redirects, etc).
> >>> Any way to separate session storage into different table instead of
> >>> one common one?
>
>
