[pylons-discuss] Depricate CallbackAuthenticationPolicy?

[Adam Terrey]

Hi All,

The concern - "the user has resisted as the user name group:editors" has
come up before in this thread
https://groups.google.com/forum/#!topic/pylons-discuss/am0mwyLOZ0w and I
also hit it as well today.

It is really easy write a vulnerable authentication configuration if decide
to use the features of CallbackAuthenticationPolicy. The thread above
suggests to prefix user names with "user:" I suppose in
security.remember(...) but that wont help you with
BasicAuthAuthenticationPolicy which makes the direct assumption that the
credentials username is going to be your userid.

I think the callback feature is too problematic, it is not mentioned in the
narrative docs which actually recommends overriding effective_principals
with a new class. That is a far better solution. Perhaps the callback
feature should be depreciated? given that it looks to be a convenience
feature that requires a lot more thought and that the more advanced
implementation is the one is the suggested one from the narrative docs.

Happy to file a bug if there are others that agree.

- Adam

[Mike Orr]

I've used the callback all along because it was Pyramid's original
paradigm and later it seemed easier than subclassing the
authentication policy. But my usernames are email addresses unless
they're created by an admin, and I prefix the groups with "g:". But
even if you don't use the callback I don't see how that helps you
because they're still all thrown into the same string pot anyway for
Pyramid's authorization, which is based on "principal" strings rather
than groups. I've never understood the reason for that. But I was
porting a Pylons application where I had to write my own group-based
auth system because there was no expert-written auth framework, so I
was glad to finally have one of those.

Post by Adam Terrey
Hi All,
The concern - "the user has resisted as the user name group:editors" has come up before in this thread https://groups.google.com/forum/#!topic/pylons-discuss/am0mwyLOZ0w and I also hit it as well today.
It is really easy write a vulnerable authentication configuration if decide to use the features of CallbackAuthenticationPolicy. The thread above suggests to prefix user names with "user:" I suppose in security.remember(...) but that wont help you with BasicAuthAuthenticationPolicy which makes the direct assumption that the credentials username is going to be your userid.
I think the callback feature is too problematic, it is not mentioned in the narrative docs which actually recommends overriding effective_principals with a new class. That is a far better solution. Perhaps the callback feature should be depreciated? given that it looks to be a convenience feature that requires a lot more thought and that the more advanced implementation is the one is the suggested one from the narrative docs.
Happy to file a bug if there are others that agree.
- Adam
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/4a1798f8-488f-4c20-b62a-544b8d1dd23f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Merickel]

Adam, I'd be interested in reviewing a PR that (at least) docs-deprecated
the feature. By this I mean removing most info about it from the docs and
pointing people at the subclassing approach - but without actually changing
the code. I've already changed at least one example in the Pyramid docs to
recommend the subclass approach [1] and I agree that it should be
recommended everywhere. As far as actually deprecating the
CallbackAuthenticationPolicy and callback argument to the policies with
future removal of that code, I do not mind if that is done but it would
need to be done carefully and with good documentation. If that's something
you're interested in, I welcome the PR! Obviously others are welcome to
object to removing the feature entirely. The best time to do it would be
*right now*. We'd deprecate it in 1.10 and remove it in 2.0 as we're
planning to do with pickle-based sessions [2].

[1]
https://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/narr/security.html#extending-default-authentication-policies
[2] https://github.com/Pylons/pyramid/pull/3353

Post by Adam Terrey
Hi All,
The concern - "the user has resisted as the user name group:editors" has
come up before in this thread
https://groups.google.com/forum/#!topic/pylons-discuss/am0mwyLOZ0w and I
also hit it as well today.
It is really easy write a vulnerable authentication configuration if
decide to use the features of CallbackAuthenticationPolicy. The thread
above suggests to prefix user names with "user:" I suppose in
security.remember(...) but that wont help you with
BasicAuthAuthenticationPolicy which makes the direct assumption that the
credentials username is going to be your userid.
I think the callback feature is too problematic, it is not mentioned in
the narrative docs which actually recommends overriding
effective_principals with a new class. That is a far better solution.
Perhaps the callback feature should be depreciated? given that it looks to
be a convenience feature that requires a lot more thought and that the more
advanced implementation is the one is the suggested one from the narrative
docs.
Happy to file a bug if there are others that agree.
- Adam
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/4a1798f8-488f-4c20-b62a-544b8d1dd23f%40googlegroups.com
<https://groups.google.com/d/msgid/pylons-discuss/4a1798f8-488f-4c20-b62a-544b8d1dd23f%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Mike Orr]

We'd deprecate it in 1.10 and remove it in 2.0 as we're planning to do with pickle-based sessions [2].

Why are pickle-based sessions being removed? I switched my serializers
to JSON but later switched them back because it was useful to have the
ability to cache non-JSONable objects in sessions.

[Michael Merickel]

Post by Michael Merickel

We'd deprecate it in 1.10 and remove it in 2.0 as we're planning to do

with pickle-based sessions [2].
Why are pickle-based sessions being removed? I switched my serializers
to JSON but later switched them back because it was useful to have the
ability to cache non-JSONable objects in sessions.

You can read the security concerns in the pull request I linked. You're
welcome to keep using pickle sessions (they support everything JSON
supports), but Pyramid will be moving to only requiring JSON.

[Mike Orr]

OK, the first time I clicked on the links I didn't see any specific
reasons but now I do. It's also interesting that you had the same
concerns I have. I'll have to go through my code and see if there's
anything non-JSONable in it now, or if I just switched back to pickle
because it was the default.

Is there a timeline for Pyramid 2? 2018 or 2019?

Post by Mike Orr

We'd deprecate it in 1.10 and remove it in 2.0 as we're planning to do with pickle-based sessions [2].

Why are pickle-based sessions being removed? I switched my serializers
to JSON but later switched them back because it was useful to have the
ability to cache non-JSONable objects in sessions.

You can read the security concerns in the pull request I linked. You're welcome to keep using pickle sessions (they support everything JSON supports), but Pyramid will be moving to only requiring JSON.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwG_bKb%2B_pZKdAd%2B-fu4NiFYcH7qxOEpDO1vQvr4YCr_Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Merickel]

Post by Mike Orr
Is there a timeline for Pyramid 2? 2018 or 2019?

There is not a timeline... probably first half of 2019 but it depends on
who contributes what when.