@Luke: A simple is_active check with return False will also do so for
the AnonymousUser.
@Łukasz:That's up to the developer of the backend I think. But with
that you could disallow logged in users from going to the registration
page for instance. (I know not a great example, but just to show the
>
> The point is that as the developer of a reusable application you don't
> know what *anyone* can do, and you should be able to abstract that by
> querying the backend.
>
+1
As a reusable app developer, I'd prefer to develop my app and ship it with a
set of permissions which control access
Am 18.01.2010 um 22:57 schrieb Alex Gaynor:
> On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel wrote:
>>
>> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>>
>>> Hi Harro,
>>>
Hmm I guess I'll just have to keep on hacking django then..
because that 1% case is
> As you say - anonymous users are by definition not *authenticated*,
> but that does not be that they are not *authorised*. Permissions is
> about authorisation, not authentication, and Harro had some good
> examples where you want to control authorisation for non-authenticated
> users in a
On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote:
> > I think the best argument in favor of it is using permissions
> > with reusable applications. Say I have a wiki application I
> > write, I don't know whether anonymous users should be able to
> > edit pages, I could make it a setting,
On Tue, Jan 19, 2010 at 3:10 PM, Ivan Sagalaev
wrote:
> Russell Keith-Magee wrote:
>>
>> There are some cases where this shouldn't happen - for example, in a
>> master/slave setup. I'm tinkering with some code at the moment to
>> control this sort of database
On Sat, Dec 19, 2009 at 10:48 PM, Russell Keith-Magee
wrote:
> On Sat, Dec 19, 2009 at 1:41 AM, Brett Hoerner wrote:
>>
>> I would think read-slaves would be a pretty common application of
>> multidb, but I can only speak to our use case. I know
On Tue, Jan 19, 2010 at 11:27 PM, Russell Keith-Magee
wrote:
> On Sat, Dec 19, 2009 at 10:48 PM, Russell Keith-Magee
> wrote:
>> On Sat, Dec 19, 2009 at 1:41 AM, Brett Hoerner
>> wrote:
>>>
>>> I would think read-slaves
Am 19.01.2010 um 16:10 schrieb Luke Plant:
> On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote:
>
>>> I think the best argument in favor of it is using permissions
>>> with reusable applications. Say I have a wiki application I
>>> write, I don't know whether anonymous users should be
@Janis: I see your point,in my proposal the default model
authentication backend always returns False for the AnonymousUser.
That would indeed mean guest users have no access at all.
But I guess you could write a wrapper that used a function specified
in the settings (with a default pointing to a
oh also: It's kinda like the messages framework rewrite now supporting
messages for anonymous users.
And I guess making it truely awesome would require permissions for
anonymoususers in the default backend too. :(
If I have timeI'll see what I can come up with.
On Jan 19, 4:34 pm, Jannis Leidel
Hi all,
We'll be holding a Django development sprint at sublab [1] in Leipzig, Germany
on January 23-24 (this saturday and sunday), starting at 10:00 AM (UTC+1).
The purpose of this sprint is to finish minor features before the complete
feature freeze on January 26, as scheduled on the roadmap
On Tuesday 19 January 2010 16:23:32 Harro wrote:
> And I guess making it truely awesome would require permissions for
> anonymoususers in the default backend too. :(
>
> If I have timeI'll see what I can come up with.
Ticket #9444 [1] is about that, and it had a lot of opposition.
It is hard
Hi folks --
I had a conversation this morning with one of my clients. In the
interests of being a good corporate citizen I'll refrain from
mentioning who other than (a) they're big (Fortune 1000), (b) you've
heard of them, and (c) they're using Django.
Before our chat, they'd invited any
The first three have been huges ones with us. We're just now running
into the settings issue, but would love to see what people can come up
with for solutions (we dont have a good one). Glad to see multi db is
finally shipping, and excited to see what can be done for startup
procs.
On Jan 19,
On Jan 20, 5:59 am, David Cramer wrote:
> The first three have been huges ones with us. We're just now running
> into the settings issue, but would love to see what people can come up
> with for solutions (we dont have a good one).
The override_settings() idea that Eric
16 matches
Mail list logo