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?
