oh, i thought you needed to have that username/hash in every url generated
by wicket. yes requestcycle.onbeginrequest is as good a place as any to sign
the user in.
-igor
On 5/17/07, Thomas R. Corbin <[EMAIL PROTECTED]> wrote:
On Thursday 17 May 2007 2:08 pm, Igor Vaynberg escreveu:
> i would extend webrequestcodingstrategy, override encode() and append
the
> parameters you need to the url it normally returns.
Sorry, but I didn't quite understand how to get the parameters I
need in the
encode method, nor how appending it would resolve the issue. I think I
just
don't quite get the encode method/encoding strategy anyway.
What I did instead was to provide my own RequestCycle class and in
onBeginRequest, look at the HttpServletRequest's uri and pull out the info
I
need and then call
AuthenticatedWebSession.get().signIn( userName, hashedPassword )
I am not sure it's entirely robust, but it does seem to work
pretty well. I
think that in the encoding strategy code I could do pretty much the same
thing, but the onBeginRequest method seems like a good place for it. It's
only that maybe in the encoding strategy code I might have a shot at a
RequestParameters object with the url info I need so I wouldn't need to
parse
the uri?
Do you think I'm heading for trouble this way?
Thanks,
Tom
>
> -igor
>
> On 5/17/07, Thomas R. Corbin <[EMAIL PROTECTED]> wrote:
> > Our client unfortunately wants to have urls be able to contain the
user's
> > login and a hashed/encrypted password so that the user can avoid
having
> > to waste time on the login page. We can't really convince them that
it
> > may not
> > be a good idea. Essentially they want single-signon, but they're not
> > prepared to work with the it department on that at this time (and I'm
not
> > sure how to do that in wicket yet, either). So what they really,
really
> > want is that when our swing app brings up a web page in a browser, we
add
> > the
> > user's login and hashed password to the url.
> >
> > But I'm having trouble figuring out how or where to grab that info and
> > bypass
> > the login page redirect, and the login page can't seem to grab that
info
> > from
> > the request. Which makes sense since the page parameters are
normally
> > really for the original page and not the login page.
> >
> > I've been looking at:
> > AuthenticatedWebApplicationonUnauthorizedInstantiation,
> > but it's final so I can't override it, and I'm not really sure if it's
> > the right place anyway. I've added my own
> > IUnauthorizedComponentInstantiationListener, but I'm not sure how to
get
> > the
> > request parameters in the listener.
> >
> > Does anyone have any hints?
> >
> > Thanks,
> > Tom
> >
> >
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
