Proper url encoding does not solve the trouble? http://oauthserver/auth?_next=http://web2py/app/default/user/login?_next=/default/index.html%26apparg&oauthserverarg=x
mic 2011/9/18 Massimo Di Pierro <[email protected]>: > Yes but the problem is that there are two "_next" variables > > - one is the page oauth should redirect to so that the oauth consumer > knows the user is being authenticated (usually that's 'user/login') > - one is the page web2py should redirect to after oauth returns. > > that means that these should be a _next inside the _next when calling > oauth, and that creates the problem. > > > On Sep 18, 2:55 pm, Michele Comitini <[email protected]> > wrote: >> Passing _next to the authenticating app is exactly what oauth specification >> does for the same problem. >> The callback URL must be under an agreed domain and path. >> >> Mic >> Il giorno 18/set/2011 19:12, "Massimo Di Pierro" <[email protected]> >> ha scritto: >> >> >> >> >> >> >> >> > I rewrite the login once more... I reverted to the old mechanism of >> > using vars=dict(_next=....) to carry one the location where to >> > redirect after login. The problem is that this _next gets lost when >> > login is outsourced (cas, janrain, others). This is difficult to fix >> > without changing the logic of many login_methods (details below). So >> > we still need to use the session logic to deal with this case. I moved >> > such logic from Auth() to auth.login(). Does this break anybody's >> > code? >> >> > The problem >> >> > you visit >> >http://..../app1/default/xxx >> > it requires login so it redirects to >> >http://..../app1/default/user/login?_next=/app1/default/xxx >> > it requires federate auth so it redirects to (*) >> >http://..../app2/default/user/login?service=http:// >> >> ..../app1/default/user/login >> >> >> >> >> >> >> >> > which does its thing and redirects back to >> >http://..../app1/default/user/login >> >> > and _next is lost. >> > At step lost we could pass >> > service=urllib.quote(http://..../app1/default/user/login?_next=/app1/ >> > default/xxx) >> >> > but I do not know for a fact how single sign on services deal with >> > variables in the service url. Each one is different It may be >> > implementation dependent. >> >> > Also is there a security risk? What if the _next is a private urls >> > that includes a uuid? Do we want to disclose it to the openid >> > provider? >> >> > Massimo >> >> > On Sep 17, 10:06 pm, Massimo Di Pierro <[email protected]> >> > wrote: >> >> There are cases when the original "next" got lost. I did not full >> >> track the cause of the problem. >> >> The code in Auth was a quick hack to handle it. >> >> >> On Sep 17, 11:26 am, Jonathan Lundell <[email protected]> wrote: >> >> >> > On Sep 17, 2011, at 8:46 AM, Massimo Di Pierro wrote: >> >> >> > > The basic use case is this: >> >> > > User clicks on a link that requires_login and gets redirected to the >> >> > > login page. After login the user is redirected to the original >> >> > > requested page. >> >> > > Exceptions: >> >> > > - the login is outsourced to janrain >> >> > > - the login is outsourced to cas or other open-id >> >> > > - the login is not possible and the user must first register >> >> > > - after login is redirected to the intended page but the app logic >> >> > > finds this user has incomplete profile and redirects to profile >> >> > > editing (*) >> >> > > - what if the user is impersonating another user? (?) >> >> > > - the user is visiting a page that does not require login but LOADs a >> >> > > component that does (?) >> >> > > - the user is visiting a page that does not require login but IFRAMEs >> >> > > a component that does >> >> > > - the user has another window open (**) >> >> > > (*) is not currently supported. (?) not sure if it works (**) worked >> >> > > with _next but not not with session._auth_next. >> >> >> > The old logic saves a next link in session in Auth(). What's that for?
