> On 19 Aug 2020, at 00:11, René Fleschenberg wrote:
>
> Or would the built-in cache backend
> just not expose those APIs?
That one.
All I’m proposing is a backend with the current API.
Over time that API has grown slightly, so maybe there’d be a case for
additional methods, but that
On Tue, Aug 18, 2020 at 12:26 PM Adam Johnson wrote:
>
> The only change we should be making is moving from separate first_name +
> last_name fields to solely a name field, since *many* people don't fit into
> that. I think there's a ticket, but there are massive backwards
> compatibility
Just my 0.02 $CURRENCY...
Interesting they're limiting the input for a security issue [at least from the
example] that manifest from not escaping _output_.
Seems related to something I learned early in my web career... about not
storing values escaped, because you don't know which medium it
Hi,
On 8/18/20 3:33 PM, Carlton Gibson wrote:
> I think we SHOULD bring a redis cache backend into core.
Would this also mean supporting Redis-specific APIs? I'm thinking of
listing keys in particular. Would Django then throw an exception on
backends that don't support this? Or would the
Hi Jure,
I think this would be a great addition to Django!
I also proposed something a few years ago which was almost identical
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ)
and had a basic implementation (it probably won't work anymore without some
tweaks).
Here's a reference from W3C on "what you should do":
https://www.w3.org/International/questions/qa-personal-names#singlefield -
with a great intro.
I'm not sure what a django.contrib.auth migration path could look like.
We'd probably want to preserve the first_name + last_name behaviour as an
>
> The recent survey showed 70% of our users using redis for caching, with
> 20%+ using memcached.
Oh I see you brought data to an opinion fight :)
Okay if those are even within 20% of the truth, it completely makes sense
to add Redis support! +1
On Tue, 18 Aug 2020 at 14:54, Tobias McNulty
Thanks Adam. I did set the value to "Anyone on the web" again (it had that
value already). And since that didn't change anything I went public:
https://twitter.com/m_holtermann/status/1295635386820157440
What _does_ work, is viewing threads directly, only showing a list of threads
doesn't work
Thank you so much for sharing that, Adam. I’ve always wondered what the best
way was to deal with names. The systems I work with should be able to handle
names from all countries of the world. I find you kalzumeus link only slightly
helpful, though. It explains what we shouldn’t do. I’d rather
On Tue, Aug 18, 2020 at 9:34 AM Carlton Gibson
wrote:
> I think we SHOULD bring a redis cache backend into core.
>
> The recent survey showed 70% of our users using redis for caching, with
> 20%+ using memcached.
>
> Nick is working on
> https://github.com/django/django/pull/13310 now.
>
>
I think we SHOULD bring a redis cache backend into core.
The recent survey showed 70% of our users using redis for caching, with 20%+
using memcached.
Nick is working on
https://github.com/django/django/pull/13310 now.
This’ll give us three memcached backends and zero for redis.
That
Maybe I spoke too quickly.
Now I'm asked for login again :-(
Claude
Le mardi 18 août 2020 13:27:35 UTC+2, Claude Paroz a écrit :
>
> Looks like it works again like before, now.
> It may have been a temporary "accident"…
>
> Claude
>
>
--
You received this message because you are subscribed to
Looks like it works again like before, now.
It may have been a temporary "accident"…
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from
Well, at least in my country there's a law that tells what characters are
allowed in names, anyway, a single name field would be cool but off topic here:
"first name" was used here as an example to illustrate that Django projects are
audited as insecure because there is no input validation at
I am against adding validation here. See the classic *Falsehoods
Programmers Believe About Names*:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
.
Here are some characters that have caused security issues in the past (e.g.
URL bar display), but I'd reckon are
Hello!
Maybe some `special_characters` bool field on models.CharField with default
to `False` would do the job?
wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)
napisał(a):
> Currently, when you order a security audit on a Django project
Currently, when you order a security audit on a Django project from any of the
firms I've seen so far (including my own), all inputs fall short on stuff like:
"First name input: allows special caracters such as <>/"' which may cause a
security issue with further developments done on the same
You're not the only one, I also get redirected to login when visiting the
group URL in a "private mode" window:
https://groups.google.com/group/django-developers
I did some research and found there's a "New Google Groups" update. I think
this has done it. Links:
- Beta announcement post:
Thanks for bringing this up, Claude. I'll look into it.
Cheers,
Markus
On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote:
> Hello,
>
> Am I the only one or did Google closed anonymous access to Google groups?
> Could it be a setting in the group config?
>
> In my opinion, it is not
Hello,
Am I the only one or did Google closed anonymous access to Google groups?
Could it be a setting in the group config?
In my opinion, it is not acceptable for the project if accessing the
Django group posts require authentication.
If someone has more information about that change, that
20 matches
Mail list logo
