(Replying on-list so that others can benefit from the question)
Hi. I've searched for this problem on the web but haven't found any solutions so i was hoping that maybe you could give me a hint.
I'm calling my Seaside application with a query parameter specifying which company database it should access (http://localhost:9090/seaside/app?site=1111111111). The problem is that when a page expires, Seaside redirects to 'http://localhost:9090/seaside/app' which makes it impossible to login again. Is there any way to alter the WAApplication's baseUrl from the code to include the parameter? Or any way to override the default expire-behaviour?
That's a tricky one - the whole point of expiring a session is to free up the memory associated with it, and so there's nowhere to maintain the state of which particular site that session was for. And it does need to be session-specific - you don't want to alter the application's base URL because that will affect all sessions in that application at once. It seems like maybe we want a mechanism almost like finalization in garbage collection, where the session itself doesn't stick around but is optionally replaced by some other, smaller object that stores a few pieces of info about the session (like, in your case, the site number), and gets control if any further requests come in for that session. It can then display the right message, do the appropriate redirect, etc. Can someone think of an appropriate name for this object? A "forwarder", maybe? (as in, the session is gone but it left a forwarding address). The Forwarder should expire too, but after a much longer period of time than the session.
This shouldn't be too hard to implement - it'll just take some messing around in #unregisterExpiredHandlers so that you send #forwarder to anything that's expired, and throw the result (if non-nil) into the new keysByHandler and handlersByKey dicts, using the same key as the expired handler its replacing. Then put a default #forwarder method that returns nil onto WARequestHandler, and override it on your session subclass to return a custom forwarder object. This will get sent #handleRequest: (and be expected to return a WAResponse) if any requests are sent to that session once its expired, and it can do whatever it likes from there. Just make sure it doesn't keep a reference to the whole session object, which would defeat the purpose. You'll also need an #isActive method (quick and dirty is just to return 'true' so that the forwarder never expires).
Unless someone can point out why this is a bad idea, or unless someone else implements it first, I'll probably post a version of the above on Monday.
Cheers, Avi
Speaking about expire, I noticed that the timeout for session is not set anywhere in 2.5b2 - dropped somewhere along the way?
rado
I noticed that too - and mailed to Avi some time ago but my mails seem to be blocked by Avi's spam filter most of the time.. ;-). I did the following:
WASession>>timeoutSeconds ^(self application preferenceAt: #sessionExpirySeconds) ifNil: [super timeoutSeconds]
BTW: Speeking about timeouts, I noticed today that WAProcessMonitor defines an instance variable and accessors named timeout which are not used anymore.
Cheers, Adrian
On Aug 27, 2004, at 8:49 PM, radoslav hodnicak wrote:
Speaking about expire, I noticed that the timeout for session is not set anywhere in 2.5b2 - dropped somewhere along the way?
rado
gentleman, n. - a man who knows how to blog, but doesn't
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
___________________ Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch
On Aug 27, 2004, at 10:37 PM, Adrian Lienhard wrote:
I noticed that too - and mailed to Avi some time ago but my mails seem to be blocked by Avi's spam filter most of the time.. ;-).
Yes, for some reason it hates you in particular...
I did the following:
WASession>>timeoutSeconds ^(self application preferenceAt: #sessionExpirySeconds) ifNil: [super timeoutSeconds]
Yes, thanks, somehow that disappeared. I'll reintroduce it.
BTW: Speeking about timeouts, I noticed today that WAProcessMonitor defines an instance variable and accessors named timeout which are not used anymore.
Nice catch, I'll clean that up.
Avi
On Aug 27, 2004, at 4:28 PM, Avi Bryant wrote:
I'm calling my Seaside application with a query parameter specifying which company database it should access (http://localhost:9090/seaside/app?site=1111111111). The problem is that when a page expires, Seaside redirects to 'http://localhost:9090/seaside/app' which makes it impossible to login again. Is there any way to alter the WAApplication's baseUrl from the code to include the parameter? Or any way to override the default expire-behaviour?
So I don't know why this didn't occur to me earlier, but the simplest way to solve this problem is just to make sure that "site=1111111" stays in the URL throughout the session. WARegistry is already set up to preserve any such parameters when it redirects you to a new session. So, on some component or decoration that's visible throughout your application (and create one if there isn't one already), just implement this method:
updateUrl: aUrl aUrl addParameter: 'site' value: '111111111'
Given that solution, what do people think about the earlier proposed forwarder/finalization mechanism? Still useful, or just bloat?
Avi
Is there any way to override the expire-screen / behaviour in the current framework? That's the only advantage i can see with the Forwarder solution.
/Adde
On 2004-09-01, at 23.35, Avi Bryant wrote:
On Aug 27, 2004, at 4:28 PM, Avi Bryant wrote:
I'm calling my Seaside application with a query parameter specifying which company database it should access (http://localhost:9090/seaside/app?site=1111111111). The problem is that when a page expires, Seaside redirects to 'http://localhost:9090/seaside/app' which makes it impossible to login again. Is there any way to alter the WAApplication's baseUrl from the code to include the parameter? Or any way to override the default expire-behaviour?
So I don't know why this didn't occur to me earlier, but the simplest way to solve this problem is just to make sure that "site=1111111" stays in the URL throughout the session. WARegistry is already set up to preserve any such parameters when it redirects you to a new session. So, on some component or decoration that's visible throughout your application (and create one if there isn't one already), just implement this method:
updateUrl: aUrl aUrl addParameter: 'site' value: '111111111'
Given that solution, what do people think about the earlier proposed forwarder/finalization mechanism? Still useful, or just bloat?
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Sep 2, 2004, at 12:22 AM, Andreas Nilsson wrote:
Is there any way to override the expire-screen / behaviour in the current framework? That's the only advantage i can see with the Forwarder solution.
Sure, just subclass WAApplication and override #handleExpiredRequest:. Changing the application class used is somewhat inconvenient, and has to be done programmatically rather than through the config app - trace through #registerAsApplication: to see how. But shouldn't be a huge deal.
Avi
Well, then I guess it's all about design goals. It is a lot easier to just hook up a plugin or event handler than it is to override classes. Overriding a class just to hook up an event is a bit like the good old days of GUI toolkits where you had to override buttons to make them do something when clicked ;)
/Adde
On 2004-09-02, at 00.30, Avi Bryant wrote:
On Sep 2, 2004, at 12:22 AM, Andreas Nilsson wrote:
Is there any way to override the expire-screen / behaviour in the current framework? That's the only advantage i can see with the Forwarder solution.
Sure, just subclass WAApplication and override #handleExpiredRequest:. Changing the application class used is somewhat inconvenient, and has to be done programmatically rather than through the config app - trace through #registerAsApplication: to see how. But shouldn't be a huge deal.
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Fair enough, but this is something that's likely to be done at most once per application... Anyway, there's no reason the expiry page can't be easily pluggable (as the error page already is). I'll take this as a request for that. But I'm still interested in whether anyone has any good uses for the #forwarder stuff that can't be just as easily handled in the URL?
On Sep 2, 2004, at 12:36 AM, Andreas Nilsson wrote:
Well, then I guess it's all about design goals. It is a lot easier to just hook up a plugin or event handler than it is to override classes. Overriding a class just to hook up an event is a bit like the good old days of GUI toolkits where you had to override buttons to make them do something when clicked ;)
/Adde
On 2004-09-02, at 00.30, Avi Bryant wrote:
On Sep 2, 2004, at 12:22 AM, Andreas Nilsson wrote:
Is there any way to override the expire-screen / behaviour in the current framework? That's the only advantage i can see with the Forwarder solution.
Sure, just subclass WAApplication and override #handleExpiredRequest:. Changing the application class used is somewhat inconvenient, and has to be done programmatically rather than through the config app - trace through #registerAsApplication: to see how. But shouldn't be a huge deal.
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Sep 2, 2004, at 12:51 AM, Avi Bryant wrote:
Fair enough, but this is something that's likely to be done at most once per application... Anyway, there's no reason the expiry page can't be easily pluggable (as the error page already is). I'll take this as a request for that. But I'm still interested in whether anyone has any good uses for the #forwarder stuff that can't be just as easily handled in the URL?
To answer my own question - it occurs to me that this is related to Kamil's earlier post titled "passing through to a new session":
Now there's one inconvenience: if user goes away from the computer after logout and then he returns back after 1-2 hours when session is too old, he/she will put there [on login form] name and password and "session expired" page will appear. Is it possible to solve this in some elegant way?
Here, the state you want to preserve is the authentication info, which doesn't seem appropriate to stick in the URL, but would be fine to preserve in a Forwarder. I think Andreas and Kamil's requests, taken together, are probably sufficient argument for the more complex mechanism...
Avi
Adding to that, I'll second Kaimil's request, it's just that i hadn't thought about it yet ;) Carrying state between sessions seems like something that you'd want to be able to do without playing around with the URL.
/Adde
On 2004-09-02, at 13.44, Avi Bryant wrote:
On Sep 2, 2004, at 12:51 AM, Avi Bryant wrote:
Fair enough, but this is something that's likely to be done at most once per application... Anyway, there's no reason the expiry page can't be easily pluggable (as the error page already is). I'll take this as a request for that. But I'm still interested in whether anyone has any good uses for the #forwarder stuff that can't be just as easily handled in the URL?
To answer my own question - it occurs to me that this is related to Kamil's earlier post titled "passing through to a new session":
Now there's one inconvenience: if user goes away from the computer after logout and then he returns back after 1-2 hours when session is too old, he/she will put there [on login form] name and password and "session expired" page will appear. Is it possible to solve this in some elegant way?
Here, the state you want to preserve is the authentication info, which doesn't seem appropriate to stick in the URL, but would be fine to preserve in a Forwarder. I think Andreas and Kamil's requests, taken together, are probably sufficient argument for the more complex mechanism...
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
While we are talking about carrying state back to the login window, many like me will also have a 'Logout' button that should also take the user to the login window with a new session while keeping the state. So you should also be able to invoke the forward from within the application, not only on expire. Or maybe the way to accomplish logout is to manually expire the session?
And, as the main purpose of the class now seems to be carrying state, 'Forwarder' is a much better name than 'Finalizer'.
/Adde
On 2004-09-02, at 13.55, Andreas Nilsson wrote:
Adding to that, I'll second Kaimil's request, it's just that i hadn't thought about it yet ;) Carrying state between sessions seems like something that you'd want to be able to do without playing around with the URL.
/Adde
On 2004-09-02, at 13.44, Avi Bryant wrote:
On Sep 2, 2004, at 12:51 AM, Avi Bryant wrote:
Fair enough, but this is something that's likely to be done at most once per application... Anyway, there's no reason the expiry page can't be easily pluggable (as the error page already is). I'll take this as a request for that. But I'm still interested in whether anyone has any good uses for the #forwarder stuff that can't be just as easily handled in the URL?
To answer my own question - it occurs to me that this is related to Kamil's earlier post titled "passing through to a new session":
Now there's one inconvenience: if user goes away from the computer after logout and then he returns back after 1-2 hours when session is too old, he/she will put there [on login form] name and password and "session expired" page will appear. Is it possible to solve this in some elegant way?
Here, the state you want to preserve is the authentication info, which doesn't seem appropriate to stick in the URL, but would be fine to preserve in a Forwarder. I think Andreas and Kamil's requests, taken together, are probably sufficient argument for the more complex mechanism...
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Sep 2, 2004, at 3:05 PM, Andreas Nilsson wrote:
While we are talking about carrying state back to the login window, many like me will also have a 'Logout' button that should also take the user to the login window with a new session while keeping the state. So you should also be able to invoke the forward from within the application, not only on expire. Or maybe the way to accomplish logout is to manually expire the session?
That makes sense to me. Just send it #expire.
And, as the main purpose of the class now seems to be carrying state, 'Forwarder' is a much better name than 'Finalizer'.
Agreed.
Avi
Avi Bryant wrote:
Here, the state you want to preserve is the authentication info, which doesn't seem appropriate to stick in the URL, but would be fine to preserve in a Forwarder. I think Andreas and Kamil's requests, taken together, are probably sufficient argument for the more complex mechanism...
I have not been reading this list for a while and finally I'm back now. I'm trying to understand how forwarder will work. Now I imagine it is something like following, I don't know if am I wrong:
- there's screen with user/password form already staying still for 2 hours, so session opened for this form is already in expired state
- user enters name and password, submits the form and because request comes from expired session, name and password entered will get saved in forwarder object
- session expired page shows up and application is redirected to main component while opening new session
- main WAComponent finds out there are some data in forwarder so it won't call login page but will invoke login process directly using data from forwarder
Is it like this?
From what i've understood by reading what Avi has said on the subject i think it's supposed to work something like this:
- When you start your session and the user has entered his/her information you create a new Forwarder object containing the information that you wan't to preserve between sessions and call a method on your session to register the forwarder object. - When the session expires, your forwarder will get the control instead of the normal expire-screen and you can then show a message and/or transfer control to your login-screen and pass along the information stored in the forwarder.
I might be wrong, though.
/Adde
On 2004-09-06, at 11.18, Kamil Kukura wrote:
Avi Bryant wrote:
Here, the state you want to preserve is the authentication info, which doesn't seem appropriate to stick in the URL, but would be fine to preserve in a Forwarder. I think Andreas and Kamil's requests, taken together, are probably sufficient argument for the more complex mechanism...
I have not been reading this list for a while and finally I'm back now. I'm trying to understand how forwarder will work. Now I imagine it is something like following, I don't know if am I wrong:
- there's screen with user/password form already staying still for 2
hours, so session opened for this form is already in expired state
- user enters name and password, submits the form and because request
comes from expired session, name and password entered will get saved in forwarder object
- session expired page shows up and application is redirected to main
component while opening new session
- main WAComponent finds out there are some data in forwarder so it
won't call login page but will invoke login process directly using data from forwarder
Is it like this?
-- Kamil _______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
seaside@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Nilsson -
Avi Bryant -
Kamil Kukura -
radoslav hodnicak