> Or why is it in 34 that the provider's internal session is expired? I don't think it matters why the session is not valid anymore, as we cannot make assumptions to the logic someone wants to implement in their custom auth provider. In the example, however, you can just assume a time out.
> I think what is missing here is something between 32 and 33 that > re-validates the custom auth provider's internal session, whenever valid > user credentials where received from a filled form. That's what I aimed for with the patch. Because the auth provider should behave differently depending on whether the user just submitted a filled-in form or the user's client simply sent the session cookie, that information has to be there. I figured the r->notes table to be the 'easiest' place to pull it from. If there exists a way to pull/derive that information from without the patch, I would like to know. On Sun, Dec 8, 2013 at 12:33 PM, Micha Lenk <mi...@lenk.info> wrote: > Hi Thomas, > > Am 03.12.2013 18:04, schrieb Thomas Eckert: > > Now suppose the following > > > > [...] > > 32 user fills in and submits form > > 32 custom auth provider receives the user credentials > > 33 custom auth provider looks up it's own session in it's module > > internal session cache > > 34 custom auth provider realizes the provider internal session expired > > I think what is missing here is something between 32 and 33 that > re-validates the custom auth provider's internal session, whenever valid > user credentials where received from a filled form. > > Or why is it in 34 that the provider's internal session is expired? > > Regards, > Micha >
