What's the best way for a transparent login?
Example: When the user opens a mounted page and he is not logged in, a login
page will be shown and after a successful login redirected to the originally
requested page.
Tom
-
I'm not sure that exist a better way to do anything in software but a
better way for specific problem and people. For me, in a spring wicket
web application, the better way to implement trasparent login aka
autentication and autorization concern is using acegi framework. Luca
2007/5/28, Thomas
The typical Wicket Way (tm) of doing this is using the
RestartResponseAtInterceptPageException [1]
The wicket-auth-roles project and the new wicket-security projects
hosted at WicketStuff also use it to guard authorized pages.
Using a framework as Acegi limits you to URL based
Should I store page parameters in the session myself before throwing the
RestartResponseAtInterceptPageException in the page's constructor? How do I
know to what page I should redirect after logging in?
Tom
Martijn Dashorst wrote:
The typical Wicket Way (tm) of doing this is using the
Never mind. RestartResponseAtInterceptPageException-handling is more
lightweight than I assumed. Of course the other processing is completely up
to me.
Tom
Thomas Singer wrote:
Should I store page parameters in the session myself before throwing the
RestartResponseAtInterceptPageException
Never mind. RestartResponseAtInterceptPageException-handling is more
lightweight than I assumed. Of course the other processing is completely up
to me.
Tom
Thomas Singer wrote:
Should I store page parameters in the session myself before throwing the
RestartResponseAtInterceptPageException in
Hm, by default, I'm getting an error that my page is not serializable. But
when I set
application.getDebugSettings().setSerializeSessionAttributes(false);
it works without problems. Could this become a problem when my page still is
not serializable?
Tom
Thomas Singer wrote:
Never mind.
On account of the serialization, yes this will become a problem for
your backbutton support.
wicket tries to serialize every page to disk and later retrieve it
when a user used the browsers backbutton and then performs an action
where it is necessary to go back to the server.
On account of the
P.S you can read more here
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
Maurice
On 5/28/07, Maurice Marrink [EMAIL PROTECTED] wrote:
On account of the serialization, yes this will become a problem for
your backbutton support.
wicket tries to serialize every page to disk
On account of the transparent login, like Martijn said if you use a
framework for your security it is already handled automagically for
you. Now i am a bit biased on the new wicket-security framework since
i wrote it :), but you should really check it out sometime.
To be exact, we don't need
Regarding the backbutton, When you press the backbutton on you're
browser, it is the browser who gets the previous page from cache, the
server is never notified of this.
So regarding wicket, no there is not much you can do on that end. But
you might be able with the help of some javascript to
On account of the serialization, yes this will become a problem for
your backbutton support.
wicket tries to serialize every page to disk and later retrieve it
when a user used the browsers backbutton and then performs an action
where it is necessary to go back to the server.
One note here
Regarding the back-button: it would be the best if the intermediate license
agreement page would not occur when pressing the back-button, but instead
the previous page (if any). Is something like that possible?
What you need to achieve is that the URL stays stable. One way to
achieve this is
13 matches
Mail list logo
