Consider google docs. You have the option to make a document readable/
writable to anybody with the URL. Imagine of creating an app similar
to that. If you use openid now the openid provider stores the uuids in
the web server logs.
I agree it is not a major concern but I am rising anyway so we ca
> Second, should we expose URLs to the openid provider? There could be a
> security implication there.
I would consider this minor, you are already naked when you use third
party authorization... ;-)
In principle. Yes. In practice, this will require changing many (all?)
of the login_methods/*.py, not just tools.py.
For example we never pass the return url to cas_auth.py, it builds it
automatically based on a prefix.
It would be hard to check all the login_methods.
Second, should we expose UR
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 :
> Yes but the problem is that there are two "_next" variables
>
> - one is the page oauth shou
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
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"
ha scritto:
> I rewrite the login once more... I reverted to the old mechanism of
>
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
In the crud case
cud.create(...,next='action/[id]')
automatically fills in the id of the record being created.
Auth allows you to the same when a new user is created.
On Sep 17, 3:30 pm, Jonathan Lundell wrote:
> On Sep 17, 2011, at 1:24 PM, Anthony wrote:
>
> > Sounds like this will be comp
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 wrote:
> On Sep 17, 2011, at 8:46 AM, Massimo Di Pierro wrote:
>
>
>
>
>
>
>
>
>
> > The basic use case is this
On Sep 17, 2011, at 1:24 PM, Anthony wrote:
> Sounds like this will be completely re-thought, so maybe comments on the
> current (trunk) code aren't necessary, but here are some observations (not
> sure if these are correct because I haven't tested anything, just quickly
> looked at the code):
Sounds like this will be completely re-thought, so maybe comments on the
current (trunk) code aren't necessary, but here are some observations (not
sure if these are correct because I haven't tested anything, just quickly
looked at the code):
- It still looks like _auth_next will be the firs
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
Fixed a typo:
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 log
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 pos
> It seems to me that there are two issues here. One is cleaning up the logic
> to make it uniform, DRY and understandable. The other is deciding where to
> put the next link (and doing proper validation of the URL).
>
> I understand (I think) the basic use case for @requires_login, I think.
>
>
@sagar: FWIW, this is what I usually do:
def login():
return dict(form=auth.login(next=request.vars._next or
auth.settings.login_next))
My site combines pages that don't require login with those that do.
On Sep 17, 2011, at 7:51 AM, Massimo Di Pierro wrote:
>> I also don't entirely understand this:
>>
>> def pop_next(self):
>> next = current.session._auth_next
>> if next and next.startswith(URL()):
>> next = current.session._auth_next = None
>> return next
> I also don't entirely understand this:
>
> def pop_next(self):
> next = current.session._auth_next
> if next and next.startswith(URL()):
> next = current.session._auth_next = None
> return next
>
> The startswith test: are we simply saying that if the start
On Sep 16, 2011, at 9:32 PM, Massimo Di Pierro wrote:
> OK. So I followed the advice and rewrote all the next logic in trunk
> (for Auth, not Crud) to use sessions.
>
> I tested with normal login, janrain and cas. It seems to work. Yet if
> you can test it too would be best.
>
> there are two we
On Sep 16, 2011, at 9:32 PM, Massimo Di Pierro wrote:
> OK. So I followed the advice and rewrote all the next logic in trunk
> (for Auth, not Crud) to use sessions.
>
> I tested with normal login, janrain and cas. It seems to work. Yet if
> you can test it too would be best.
>
> there are two we
OK. So I followed the advice and rewrote all the next logic in trunk
(for Auth, not Crud) to use sessions.
I tested with normal login, janrain and cas. It seems to work. Yet if
you can test it too would be best.
there are two weird cases (and they were weird before):
- app A redirect to CAS provi
On Sep 16, 2011, at 6:28 PM, Anthony wrote:
> On Friday, September 16, 2011 4:56:17 PM UTC-4, Massimo Di Pierro wrote:
>
> should it just be?
>
> if not self.user:
> if not session._auth_next:
> session._auth_next = URL(args=request.args,
>
On Friday, September 16, 2011 4:56:17 PM UTC-4, Massimo Di Pierro wrote:
>
>
> should it just be?
>
> if not self.user:
> if not session._auth_next:
> session._auth_next = URL(args=request.args,
> vars=requ
On Sep 16, 2011, at 1:56 PM, Massimo Di Pierro
wrote:
> It is not handle adequately if the app uses an external
> authentication. perhaps there is a better solution... let me think
> about this some more.
>
> Basically the issue is this code in web2py/gluon/tools.py
>
>if auto_redire
It is not handle adequately if the app uses an external
authentication. perhaps there is a better solution... let me think
about this some more.
Basically the issue is this code in web2py/gluon/tools.py
if auto_redirect and URL() in auto_redirect:
if not self.user:
On Friday, September 16, 2011 3:00:59 PM UTC-4, Jonathan Lundell wrote:
>
> On Friday, September 16, 2011 2:21:07 PM UTC-4, Jonathan Lundell wrote:
>
> > Sometimes I think the need for auto_redirect is paranoid.
>>
>> What's the hazard? Presumably there's nothing to stop the user from going
>> to
I did not notice that feature
-1
. adds complexity in API and code
. not a security feature
IMHO it is more dangerous than nothing
mic
2011/9/16 Jonathan Lundell :
> On Sep 16, 2011, at 11:35 AM, Anthony wrote:
>
> On Friday, September 16, 2011 2:21:07 PM UTC-4, Jonathan Lundell wrote:
>>
>>
On Sep 16, 2011, at 11:35 AM, Anthony wrote:
> On Friday, September 16, 2011 2:21:07 PM UTC-4, Jonathan Lundell wrote:
> > Sometimes I think the need for auto_redirect is paranoid.
>
> What's the hazard? Presumably there's nothing to stop the user from going to
> the same URL after a successful
On Friday, September 16, 2011 2:21:07 PM UTC-4, Jonathan Lundell wrote:
>
> > Sometimes I think the need for auto_redirect is paranoid.
>
> What's the hazard? Presumably there's nothing to stop the user from going
> to the same URL after a successful login, so why not automatically?
>
This: https:
On Sep 16, 2011, at 11:13 AM, Massimo Di Pierro wrote:
> auto_redirect works for any redierct, even if not relative.
> So you send an email like
>
> click here
> http://./app/path
>
> and if http://./app/path requires login, you get redirected to
> login but not back to http://./app/
auto_redirect works for any redierct, even if not relative.
So you send an email like
click here
http://./app/path
and if http://./app/path requires login, you get redirected to
login but not back to http://./app/path unless '/app/path' is in
auto_redirect.
Internally is still uses _n
On Friday, September 16, 2011 12:57:07 PM UTC-4, Massimo Di Pierro wrote:
>
> This is in general a security hazard so it needs to be enabled:
>
> auth = Auth(db,auto_redirect=[URL(...),URL(...)])
>
> where URL(...) are the urls where it is safe to redirect to after
> login if originally requeste
This is in general a security hazard so it needs to be enabled:
auth = Auth(db,auto_redirect=[URL(...),URL(...)])
where URL(...) are the urls where it is safe to redirect to after
login if originally requested. trunk only.
On Sep 16, 10:45 am, sagar nigade wrote:
> yes I have definded decorater
33 matches
Mail list logo
