Planned updates to Django auth integration

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Planned updates to Django auth integration

Nick Joyce
Hey all,

I am currently in the process of providing Django 1.2 support for the upcoming PyAMF 0.6 release. As part of these updates, I have been looking at deeper integration with django.contrib.auth, specifically providing some defaults so that people can use Django auth with AMF without thinking about it too much ..

The changes force django.contrib.auth.models to be aliased (via pyamf.register_class) which allows us to provide some default attribute control, including excluding the password, setting the username to readonly (see [1] for more detail on why that is a good thing).

This is a backward incompatible change and I would like some opinions on whether this is a good thing or not, how we can make it easy for people to migrate etc.

Are there any other parts of Django that could/should be better supported?

What do you think?

Nick

[1] - http://pyamf.org/architecture/attributecontrol.html

_______________________________________________
PyAMF users mailing list - [hidden email]
http://lists.pyamf.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Planned updates to Django auth integration

Jesse Warden-2
Sounds great to me; the exclude stuff is something you'd want in there by default anyway.  If you know what you're doing, you'll do it on every project.  If you don't, you're in bad shape.

On Thu, Mar 11, 2010 at 5:25 AM, Nick Joyce <[hidden email]> wrote:
Hey all,

I am currently in the process of providing Django 1.2 support for the upcoming PyAMF 0.6 release. As part of these updates, I have been looking at deeper integration with django.contrib.auth, specifically providing some defaults so that people can use Django auth with AMF without thinking about it too much ..

The changes force django.contrib.auth.models to be aliased (via pyamf.register_class) which allows us to provide some default attribute control, including excluding the password, setting the username to readonly (see [1] for more detail on why that is a good thing).

This is a backward incompatible change and I would like some opinions on whether this is a good thing or not, how we can make it easy for people to migrate etc.

Are there any other parts of Django that could/should be better supported?

What do you think?

Nick

[1] - http://pyamf.org/architecture/attributecontrol.html

_______________________________________________
PyAMF users mailing list - [hidden email]
http://lists.pyamf.org/mailman/listinfo/users


_______________________________________________
PyAMF users mailing list - [hidden email]
http://lists.pyamf.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Planned updates to Django auth integration

Marcin Wielgoszewski
In reply to this post by Nick Joyce
With support for Django authentication + AMF, are you suggesting that
users will be able to load a SWF prior to successful authentication?
I think this is a bad idea from a security perspective, as you may end
up exposing application logic to unauthenticated users.

-Marcin

On Thu, Mar 11, 2010 at 9:25 AM, Nick Joyce <[hidden email]> wrote:

> Hey all,
>
> I am currently in the process of providing Django 1.2 support for the upcoming PyAMF 0.6 release. As part of these updates, I have been looking at deeper integration with django.contrib.auth, specifically providing some defaults so that people can use Django auth with AMF without thinking about it too much ..
>
> The changes force django.contrib.auth.models to be aliased (via pyamf.register_class) which allows us to provide some default attribute control, including excluding the password, setting the username to readonly (see [1] for more detail on why that is a good thing).
>
> This is a backward incompatible change and I would like some opinions on whether this is a good thing or not, how we can make it easy for people to migrate etc.
>
> Are there any other parts of Django that could/should be better supported?
>
> What do you think?
>
> Nick
>
> [1] - http://pyamf.org/architecture/attributecontrol.html
>
> _______________________________________________
> PyAMF users mailing list - [hidden email]
> http://lists.pyamf.org/mailman/listinfo/users
>
_______________________________________________
PyAMF users mailing list - [hidden email]
http://lists.pyamf.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Planned updates to Django auth integration

Nick Joyce
Securing the swf is out of the scope of PyAMF. I am referring to using the auth system with Django through PyAMF, encoding and decoding User or AnonymousUser objects over the wire.

Cheers,

Nick

On 15 Mar 2010, at 21:05, Marcin Wielgoszewski wrote:

> With support for Django authentication + AMF, are you suggesting that
> users will be able to load a SWF prior to successful authentication?
> I think this is a bad idea from a security perspective, as you may end
> up exposing application logic to unauthenticated users.
>
> -Marcin
>
> On Thu, Mar 11, 2010 at 9:25 AM, Nick Joyce <[hidden email]> wrote:
>> Hey all,
>>
>> I am currently in the process of providing Django 1.2 support for the upcoming PyAMF 0.6 release. As part of these updates, I have been looking at deeper integration with django.contrib.auth, specifically providing some defaults so that people can use Django auth with AMF without thinking about it too much ..
>>
>> The changes force django.contrib.auth.models to be aliased (via pyamf.register_class) which allows us to provide some default attribute control, including excluding the password, setting the username to readonly (see [1] for more detail on why that is a good thing).
>>
>> This is a backward incompatible change and I would like some opinions on whether this is a good thing or not, how we can make it easy for people to migrate etc.
>>
>> Are there any other parts of Django that could/should be better supported?
>>
>> What do you think?
>>
>> Nick
>>
>> [1] - http://pyamf.org/architecture/attributecontrol.html
>>
>> _______________________________________________
>> PyAMF users mailing list - [hidden email]
>> http://lists.pyamf.org/mailman/listinfo/users
>>
> _______________________________________________
> PyAMF users mailing list - [hidden email]
> http://lists.pyamf.org/mailman/listinfo/users

_______________________________________________
PyAMF users mailing list - [hidden email]
http://lists.pyamf.org/mailman/listinfo/users