On Thursday, April 20, 2023 at 1:00:05 PM UTC+2 Jure Erznožnik wrote:
OK, I'll bite:
For the first issue, my problem revolved around this code:
@property def POST(self): # Ensure that request.POST uses our request
parsing. if not _hasattr(self, '_data'): self._load_data_and_files() if
Hi,
On Tuesday, April 18, 2023 at 10:57:55 PM UTC+2 jure.er...@gmail.com wrote:
Well, TBH, I've just completed dealing with CSRF form in my projects. I
ended up exempting the particular view from CSRF because I didn't know how
to get the stuff to work. The problem was that django parsed the
Hi, this is something which is already supported via the template argument
to startproject/startapp.
Cheers,
florian
On Sunday, April 16, 2023 at 11:47:44 PM UTC+2 Daniel Azubuine wrote:
> When starting a new Django project, the user can select if he wants to
> build an API or use the Django
On Sunday, April 16, 2023 at 10:21:20 AM UTC+2 Adam Johnson wrote:
One question though, how will we support projects that are served at
multiple domains? Would Django only support the "main" site through
BASE_URL and require you to perform URL construction for other domains as
required?
As
The thread that Carlton refers to is
https://groups.google.com/g/django-developers/c/q20_Cxske88 -- don't be
deterred by the title of it, it really talks about handling settings as
well :)
I kinda agree with James. I'd like to have a proper answer for handling
settings rather then go setting
Hi,
+1 from me, but I'd like to ask the wider community (ie DSF members)
whether they support this change.
While there has been some opposition on whether a change likes this will
actually change things, I think that given the overall good reception of
the proposal it is at least worth to try
I do have ideas but no idea about how viable they are in a GSoC context.
Nevertheless I will put write them down here, maybe we can find smaller
scopes if needed and if not, it still serves as a list of things that I'd
think to be interesting:
* Probably my number one since it kinda is a
...@feinheit.ch wrote:
> On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner
> wrote:
>
>> Right, that would work. I am wondering though if we want to go all in on
>> a typed config object like that or in a first step only have a simple API
>> like `config.get('DEBUG', c
11:52 AM Florian Apolloner
> wrote:
>
>> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
>> wrote:
>>
>>> In my ideal scenario, the default is a hard-coded settings file for the
>>> project (deprecating DJANGO_SETTINGS_MODULE env
On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com wrote:
> In my ideal scenario, the default is a hard-coded settings file for the
> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>
Hi Tobias,
On Sunday, October 30, 2022 at 2:02:36 AM UTC+2 tob...@caktusgroup.com
wrote:
> Regarding DJANGO_ENV, why not ship the template with two settings files
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
> environment variable?
>
That is certainly one way to do
Hi Peter,
On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
wrote:
> Since you asked for feedback, I'll tell you what I'd do differently (and
>> this is also a sign that production environment vary widely).
>>
>
> Production environments do vary widely, but I don't think
(no sarcasm
> here).
>
> LP,
> Jure
>
> On 26. 10. 22 09:30, Florian Apolloner wrote:
>
> Hi Pete,
>
> this does look interesting. And I agree that this is something that would
> be nice to have in core in one form or another. That said I think we have
> to
Hi Pete,
this does look interesting. And I agree that this is something that would
be nice to have in core in one form or another. That said I think we have
to do it iteratively (ie in smaller parts) and evaluate along the way.
Since you asked for feedback, I'll tell you what I'd do
Hi James,
On Tuesday, October 25, 2022 at 12:27:03 AM UTC+2 James Bennett wrote:
> On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin wrote:
>
>> Proposing features - this is already in DEP 10, so I more just want to
>> get that aspect of the Board actually going (and, as a side-effect, have
>>
Hi Chris,
On Tuesday, June 7, 2022 at 11:30:46 AM UTC+2 christopher@gmail.com
wrote:
> The question is how to add support cleanly so that both names are
> supported in 4.1? Is there a preference? Particularly how can it be be
> done to reuse code without (temporary) duplication?
>
Good
Hi Maciej,
You can already customize the cookie name via a setting. What this request
is asking is customization based on the request object which is not that
common. Did you check that you configured your applications correctly to
use different cookie names
Hi Chris,
a thin client seems like great news to me :)
On Friday, May 27, 2022 at 3:05:51 PM UTC+2 christopher@gmail.com wrote:
> 1a. What about completely replacing cx_Oracle with python-oracledb
> (oracledb)? Python-oracledb is just a major release of cx_Oracle with a new
> name. We
On Thursday, May 12, 2022 at 1:33:38 PM UTC+2 thinkwel...@gmail.com wrote:
> > Next step would be someone to pick the preliminary work up and push it
> forward.
>
> I guess I thought the "preliminary work" was already done. There's a
> driver written, and a PR for a django backend.
>
I don't
Hi Jörg,
Regarding your question about database version support:
https://docs.djangoproject.com/en/4.0/ref/databases/ lists the supported
versions. Granted not as support grid and you have to scroll to every
database, but it is usually in the first paragraph.
If f-expressions are currently
Hi Yonas,
that is an unfair characterization of WebAuthn. WebAuthn supports
passwordless authentication as strong first factor (albeit often supporting
a limited number of credentials because it requires storage on the device).
But Webauthn also (and this is imo more widely used) supports a
Hi Jacob,
I am afraid this does not help much at all. Assuming a malicious client
wants to attack you, they can still just issue one request to get this
"other hidden field". Then they wait 5 seconds and are free to send
thousands of requests with that token (Well till it expires, then they
Hi Yonas,
On Friday, April 8, 2022 at 3:18:23 AM UTC+2 Yonas wrote:
> There are multiple ways to implement MFA, as you mentioned. But the goal
> here is to provide a simple mechanism. It's "not necessary" to cover every
> use case, and I believe that's where third-party packages come in.
>
Hi Tim,
On Friday, April 1, 2022 at 5:02:00 PM UTC+2 Tim Allen wrote:
> The DB popularity index at db-engines.com has regularly listed the top
> four as Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, in that order.
> I notice some comments in this thread about Microsoft being
Hi Waren,
On Thursday, March 31, 2022 at 6:30:06 PM UTC+2 vwa...@gmail.com wrote:
> We'd love to hear thoughts and feedback around the possibility of moving
> forward with a DEP enhancement proposal, with a commitment from Microsoft
> to providing continued dedicated support for the 1st party
Hi Adrian,
On Saturday, March 5, 2022 at 5:13:14 PM UTC+1 ator...@redhat.com wrote:
> - Existing RemoteUserBackend implementations won't need to change
> signatures whenever backwards compatibility is removed
> - RemoteUserBackend implementations won't need to do anything in order to
> support
Hi Adrian,
I agree this would be nice to have.
On Friday, March 4, 2022 at 8:03:09 PM UTC+1 ator...@redhat.com wrote:
> Another idea would be to use configure_user() for both initial
> configuration and synchronization by passing an extra parameter "created"
> to it, and calling it just
Oh. AWS just hates us :) Thanks, we are looking into it.
On Friday, March 4, 2022 at 5:55:00 PM UTC+1 charettes wrote:
> Hi everyone,
>
> I'm not sure if we're already aware of the issue but it seems that Trac
> hasn't published any changes to the Django Updates Google Group[0] since
> March
disseminated, distributed or copied. If you have received this email and it
>> was not for you, please notify the sender by email immediately and
>> afterward delete this email from your system. Disclosing, copying,
>> distributing, or taking any action in reliance on the ema
I do not understand why you would need multiple email backends to send from
different addresses. Can you elaborate on that?
On Sunday, January 30, 2022 at 1:18:48 PM UTC+1 st...@jigsawtech.co.uk
wrote:
> I've a big +1 on changing email config to a dictionary to support multiple
> backends as
Hi Jacob,
I wouldn't be opposed to move email configuration into a dictionary
(somewhere between -0 and +0). Although if we plan to do that we should
rethink all the existing session variables and other as well I guess and
figure out if we should move more settings to dictionaries.
> why
Hi,
I agree that we should treat session cookies as sensitive and hide them
like we do with passwords. That said, please be aware that all the
SafeException reporters are best effort and it is generally not possible to
have a "safe" exception.
In that sense, patches welcome but we are not
Hi,
On Tuesday, January 4, 2022 at 2:09:18 PM UTC+1 Sjoerd Job Postmus wrote:
> Unfortunately (at least for us), this breaks the case where dictsort was
> used with a static argument that looked up a callable. A quick code search
> showed that the pattern dictsort.*get (
>
Hi Aymeric,
On Saturday, November 20, 2021 at 12:39:17 PM UTC+1 Aymeric Augustin wrote:
> I'm not trying to disagree for the sake of disagreement; I'm just trying
> to bring some contextual awareness and avoid the "core devs say
> ATOMIC_REQUESTS is bad" effect. I hope we can agree on this?
>
On Wednesday, November 17, 2021 at 11:09:58 PM UTC+1 Adam Johnson wrote:
> FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
> are used by default in other code paths such as background tasks.
>
FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions
Because the scoping of the transactions makes it hard I imagine. A view
could start more than one transaction for instance, and one of those might
succeed and the other might get rolled back. Thinking more about this, a
system like this might get hard to implement. Even if thread locals are
On Friday, October 8, 2021 at 6:14:19 PM UTC+2 dhruv...@gmail.com wrote:
> Ik range function can be added but I also mentioned that there are some
> cases range function can't be direct generated from the view like this
>
On Wednesday, July 21, 2021 at 11:18:41 AM UTC+2 carlton...@gmail.com wrote:
> As such, I would like to nominate Florian as a new Releaser, and ask the
> TB to discuss/vote on that in accordance with DEP 10.
>
Given that I am on the TB I will not participate in the vote -- even though
I do
As long as runserver (usually) properly shuts down when CTRL-C is hit, then
it imo makes sense to change the text -- especially if that is the only
thing accessible on some keyboards.
The usually above is because someone might have a bare except that is hit
that moment and as such the process
On Tuesday, June 1, 2021 at 2:35:17 PM UTC+2 gojeta...@gmail.com wrote:
> I don't see any reason for why providing a hook seems so difficult.
>
It is more code to maintain, needs tests etc and increases complexity. Just
because something is easy on the surface, doesn't mean it will be easy in
On Tuesday, June 1, 2021 at 1:45:29 PM UTC+2 Aymeric Augustin wrote:
> I would recommend running without persistent database connections
> (CONN_MAX_AGE = 0) and switching settings.DATABASE["default"] in a
> middleware at the beginning of every request. Modifying settings at runtime
> isn't
On Monday, May 31, 2021 at 12:13:58 PM UTC+2 Adam Johnson wrote:
> I'm also -1 on changing anything in Django right now.
>
-1 as well, I simply see no way how something like:
```
with transaction.atomic():
Model1.objects.create()
Model2.objects.create()
```
will allow for any
Hi Chris,
nice hearing from you.
On Friday, May 7, 2021 at 6:20:44 PM UTC+2 chris.j...@gmail.com wrote:
> With the suggested work-around of having a view call other views, would a
> view be able to continue URL resolution in that case?
>
Not without many code changes I fear and I am not sure
On Thursday, May 6, 2021 at 10:19:42 PM UTC+2 Adam Johnson wrote:
> That said, I think doing this in process_response would be preferable over
>> doing it in process_request so the extra checks when the URL is valid (the
>> common case) are reduced. Resolving URLs can take a bit, especially
Hi,
I took a quick glance (literally just that) at the pull requests. I do like
the one that offers a way to abort early inside a prefix -- this is a nice
optimization and as well might open interesting options for specialized
catch all views. I am not convinced about the backtracking PR,
On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote:
> In both cases however, the current check being done in the
> process_response method for the CommonMiddleware(here
>
On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:
> I also don't think this is necessary any more and can be closed.
>
>
>> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine
>> to be honest, for those that need it.
>
>
> I also would like to meet the
Maybe wait with featuring till the licensing issues are cleared up.
https://github.com/microsoft/mssql-django/issues/15 does not leave a good
impression on a first glance.
On Friday, March 26, 2021 at 1:48:50 PM UTC+1 wi...@wsvincent.com wrote:
> Yes, what Adam said! We'll certainly feature
Thank you for diving into how unittest discovery tests!
On Friday, March 12, 2021 at 12:14:05 PM UTC+1 chris.j...@gmail.com wrote:
> But, regardless of the default, to get the full benefit I think you'd want
> at least one of the test runs in CI to be a random one.
>
This is were I somewhat
from the PR number or so, because I think the number of tests inside a PR
is small enough that you probably do not see isolation failures, but you
really want to see progress in a PR without random failures due to
isolation.
On Friday, March 12, 2021 at 10:47:56 AM UTC+1 Florian Apolloner wrote
Is the current order defined in any way -- if not one should consider it
randoms anyways and as such actually randomizing should not make much of a
difference. FWIW I am fine with making it the default and outputting the
seed at the end of the run so it can reproduced. I am curious if it finds
Mhm, I expected such an answer when I hit send :) I maybe should have
worded it better. While you are right, that ultimately this is an issue for
the DSF board I think that most of those issues can be solved by asking
authors/etc nicely without having to invoke the thread of trademarks or
I am in favor of removing such a package. FWIW I have been contacting the
authors of https://pypi.org/project/Django-2.2.19/ and
https://pypi.org/project/Django-504/ as well a few weeks ago (their
packages list before or next to Django when searching for Django on PyPI
and might create some
> Except for our LTS versions, which would never drop support.
Mhm, I'd support such an approach only if we have a clear idea for security
issues. Assume LTS supports Python 3.x to 3.z. Python 3.x goes EOL and has
a security issue that affects Django LTS -- what do we do? On one hand
there
Hi Simon,
On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
> I think that's the best option here if we want to elegantly add support
> for this feature while maintaining backward compability. Something along
> the lines of ...
>
That is certainly an interesting approach. It
Hi Scott,
Thank you for your response, this is very helpful.
On Tuesday, January 26, 2021 at 11:38:18 PM UTC+1 foug...@apps.disney.com
wrote:
> Snowflake does not support lastrowid. So, we grab the last ID inserted
> with a 'SELECT MAX(pk_name) FROM table_name'. This is obviously prone to
On Tuesday, January 26, 2021 at 5:26:02 PM UTC+1 Adam Johnson wrote:
> Not that I am completely convinced that the following is a good idea; but
>> what about:
>
> QuerySet.objects.update(name="Rob").values("id", "name")
>>
>
> That's not possible since update() directly performs the update -
Not that I am completely convinced that the following is a good idea; but
what about:
QuerySet.objects.update(name="Rob").values("id", "name")
On second thought I'd like an .returning() more than values, but I am not
sure if it makes sense to add a new function just for the sake of a small
On Saturday, January 23, 2021 at 12:41:35 AM UTC+1 t...@tomforb.es wrote:
> > Honestly, I don't think we'd release this as a third party package. We
> have had to code around a lot of core db specific code to get Snow SQL to
> work
>
> This is good feedback that is valuable for us to hear.
On Thursday, January 7, 2021 at 2:16:57 PM UTC+1 carlton...@gmail.com wrote:
> 1. Add the catch-all view to admin to stop the unauthenticated probing, as
> per the Security Teams initial idea, but not the AdminSite.append_slash
> option.
> 2. Don't even add the catch-all, and close the ticket
Hi Carlton,
I'd like to put
https://github.com/django/django/pull/12553
https://github.com/django/django/pull/13800
onto this list as well. They are imo basically finished and I'd love
reviews from our fellows. Let me know if I can help somewhere else in
exchange ;)
Cheers,
Florian
On
On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 diptesh@gmail.com
wrote:
> and having to add a bunch of unnecessary files to the source code
A bunch? You can literally get away with one file:
➜ testing git:(dc_message_signing) ✗ tree testabc
testabc
└── management
└── commands
Nothing is stopping pytest-django to also ship a django app for those
management commands though
On Saturday, December 19, 2020 at 2:27:57 PM UTC+1 diptesh@gmail.com
wrote:
> As you said, most cases. The remaining cases have absolutely no way of
> defining management commands. One example
Hi there,
Craig Smith is working on making cookie-based messages RFC compliant
(https://code.djangoproject.com/ticket/32191). Our prefered approach would
be to encode messages via `signing.dumps` and this is (excuse the wording)
where the shitshow begins. As it currently stands we cannot use
Hi Warren,
> A) django-mssql is viewed as the Phase 1 focus and current preferred
option with a longer term Phase 2 goal of including MSSQL as a supported
backend for Django core
Please keep in mind that Phase 2 is something that might never happen. We
have a tendency to not bloat Django and
Hi Warren,
given that the current django-mssql-backend maintainers might not be
reading here I'd suggest you open a ticket on the repository to get in
contact with them. It also might be a good idea to re-evaluate this thread
(and possibly at Microsoft internally) to see why the last
I think Redhat realized that they have old versions and this is not going
to fly well during the lifetime of their system. This is why they
introduced modules in v8 and strongly pushing podman. That said, it is a
major hurdle for many companies if upstream drops support for $x (be that
in
Hi,
I am not sure what you are trying to tell us?! Opening a connection to
Postgresql is somewhat time-consuming and 10ms in a cloud env does not seem
to be surprising at all.
Cheers,
Florian
On Monday, October 26, 2020 at 2:28:28 PM UTC+1 pra...@fampay.in wrote:
>
So, I have been digging a little bit more and it seems there was a
conscious decision to not include an entropy check or character classes:
https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/toKKgGhaqewJ
-- But I have to admit that this is all I could find and I was rather
surprised
Seem to be expected behaviour (albeit somewhat suboptimal :D). The default
validators are:
https://github.com/django/django/blob/999cddd58d30469f3ee85278985313fdf528323d/django/conf/project_template/project_name/settings.py-tpl#L87-L100
and from the looks of it / is in the list
Hi Adam,
On Monday, September 14, 2020 at 2:00:06 PM UTC+2 Adam Johnson wrote:
> one thing to consider might be that md5 is usually disabled for FIPS
>> enabled system
>>
>
> This is true, but if no one has complained, why "fix" it? As covered above
> one can always implement custom ETag
Hi,
one thing to consider might be that md5 is usually disabled for FIPS
enabled system (ie https://code.djangoproject.com/ticket/28401 ). So if we
are changing something here we might also consider this.
Cheers,
Florian
On Friday, September 11, 2020 at 9:41:51 AM UTC+2 gertb...@gmail.com
On Thursday, September 10, 2020 at 11:16:56 AM UTC+2 Alexander Lyabah wrote:
> The problem with the function is that it is actually working, but not
> always, and because of that, other people are suggesting it on
> StackOverflow, using it in prod, and may, eventually catch weird
> exceptions,
On Thursday, September 3, 2020 at 11:10:39 AM UTC+2 Adam Johnson wrote:
> You could also move to use the Argon2 hasher, which does not have any
> chagnes between versions to log out users:
> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#using-argon2-with-django
>
Or a custom
I do not think there is anything to reopen because it works as designed.
Password changes cause other browser sessions to be terminated because the
session auth hash no longer matches. You can use a custom user model and
override `get_session_auth_hash` but the defaults won't change, sorry.
On Wednesday, August 19, 2020 at 2:01:51 AM UTC+2 cur...@tinbrain.net wrote:
> Seems related to something I learned early in my web career... about not
> storing values escaped, because you don't know which medium it needs
> escaping for -- e.g. HTML needs different escaping than URLs.
>
On Saturday, August 1, 2020 at 12:53:09 PM UTC+2 Florian Apolloner wrote:
> And also, how to define this setting to its default value in Django
>> versions <= 3.0.
>>
>
> You don't, this is not supported.
>
Sorry I probably didn't fully understand the question
On Saturday, August 1, 2020 at 7:16:57 AM UTC+2 Uri wrote:
> How do you propose running several versions of Django 3.0 and 3.1 with
> this PR and setting? Does it have to be defined, or is it enough using the
> default setting?
>
You have to set it to `sha1` and then when all your instances
Comments like these are inappropriate for this mailing list. Stop spamming
your whatsapp number all over the place.
On Sunday, July 26, 2020 at 6:00:47 PM UTC+2 mithileshr...@gmail.com wrote:
> ok whatsapp +918709440658 <+91%2087094%2040658>
>
> On Fri, 10 Jul 2020, 2:54 pm '1337 Shadow Hacker'
There are also various issues in python itself like
https://bugs.python.org/issue23882 -- so I strongly recommend against
namespace packages unless you actually need them.
On Monday, July 20, 2020 at 1:14:41 AM UTC+2 re...@fleschenberg.net wrote:
> Hi,
>
> On 7/19/20 10:25 PM, Tim Graham
.
On Sunday, June 28, 2020 at 10:27:44 AM UTC+2 Florian Apolloner wrote:
> On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote:
>
>> It seems like it could be insecure to move that to a system check as "For
>> performance reasons, checks are not run as
On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote:
> It seems like it could be insecure to move that to a system check as "For
> performance reasons, checks are not run as part of the WSGI stack that is
> used in deployment." (Also, it seems impossible to write a system
Hi Tom,
On Friday, June 26, 2020 at 12:43:19 PM UTC+2 t...@carrick.eu wrote:
> I do have a use-case where having a default SECRET_KEY makes things much
> easier - docker.
>
> Normally you can't run management commands in a Dockerfile if there's no
> secret key (and often other things) set, and
Hi there,
On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com wrote:
> Personally, I think that *at minimum* providing Django-builtin "get from
> env" helpers would be great; beyond that, I'd love to have them be
> included around `DEBUG` and `SECRET_KEY` with the current values
hours ago. :)
>
> Onward,
> Arvind
>
> Sent from Outlook Mobile <https://aka.ms/blhgte>
>
> --
> *From:* django-d...@googlegroups.com <
> django-d...@googlegroups.com > on behalf of Florian
> Apolloner >
> *Sent:* Tuesday, June 16,
If you look at the mails beyond the first one, you will see that Josh &
Carlton already came to that conlusion ;)
On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
>
> Could you elaborate on how this is different from extending a base
> template and re-defining the
Ok, so rebasing PRs to current master will fix this (leaving this here as
note for others who run into this).
On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote:
>
> It's an issue with the asgiref==3.2.8, see
> https://github.com/django/asgiref/issues/170. We temporarily
Hi,
do we have any idea what is happening on
https://djangoci.com/job/pr-mariadb/database=mysql,label=mariadb,python=python3.8/6459/
? It seems as if (mostly) the same set of tests is failing over and over.
Is this ASGI/concurrency related?
Cheers,
Florian
--
You received this message
On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>
> If you already fetched the queryset, `if obj in queryset` will make a new
>> database query
>
>
> I don't see why we couldn't implement __contains__ to do a walk through
> _result_cache if it has been fetched?
>
we are doing
On Wednesday, May 13, 2020 at 4:40:55 PM UTC+2, Adam Johnson wrote:
>
> This looks good to me, it fits the preset release cadence. Although the
> final release will be on "April fools day," it's something we've done
> several times before.
>
While we might have done it (did we actually do that
On Saturday, May 9, 2020 at 1:41:41 PM UTC+2, Aymeric Augustin wrote:
>
> - Users who don't know that GET queries mustn't have side effects and who
> don't want to bother will have an incentive to use a POST query to get the
> data in form_data; this is the safe option with regards to CSRF;
>
On Wednesday, May 6, 2020 at 5:49:40 PM UTC+2, Adam Johnson wrote:
>
> Would just like to point out - that's not the proposal. The proposal is to
> rename the existing request.POST to request.form_data, which is based on
> parsing application/x-www-form-urlencoded data from request.body.
oh, I somehow missed that. thanks for the heads-up.
--
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 it, send an email
to
On Thursday, March 12, 2020 at 6:16:31 PM UTC+1, Dawid Czeluśniak wrote:
>
> I think that the root question here is: should we allow users to create
> passwords from anything that is not str?
>
I would reduce it to allow strings & bytes and am willing to review a patch
and push it through. It
Hi Adam,
On Wednesday, March 25, 2020 at 7:27:58 PM UTC+1, Adam Johnson wrote:
>
> I think that would make Florian happy, although it *has* been seven years
> since his closing comment on the ticket.
>
You should know me better :D No this would not make Florian happy and he is
still against
UX wise the intermediary page is annoying. So if we can just provide some
docs and upgrade notes I'd be fine with just dropping the get part.
On Thursday, March 5, 2020 at 5:40:25 PM UTC+1, René Fleschenberg wrote:
> Hi,
>
> On 04.03.20 12:13, Sam Willis wrote:
> > Why not have the logout
I found an example on stackoverflow on how we could do this in the admin
without JS (with a bit of styling): https://stackoverflow.com/a/33880971 --
I personally would prefer it if we would not need javascript for a
fundamental functionality like this.
On Saturday, February 29, 2020 at 9:26:23
On Friday, February 28, 2020 at 5:08:07 PM UTC+1, Maher, Brian wrote:
>
> Are any current browsers dumb enough to prefetch logout links these days?
> I would assume that most prefetch algorithms are smart enough to not
> pre-fetch these.
>
Not sure what heuristics browsers use.
I have also
On Wednesday, November 6, 2019 at 4:48:11 PM UTC+1, Tom Forbes wrote:
>
> The usage limits are documented here:
> https://help.github.com/en/github/automating-your-workflow-with-github-actions/about-github-actions#usage-limits.
>
> I’m not sure how they apply to organisations (maybe just
On Wednesday, November 6, 2019 at 8:43:21 AM UTC+1, Shai Berger wrote:
>
> Is there benefit enough in GitHub Actions (over Jenkins) to justify a
> move from an open-source based solution?
>
Yes, less server costs (even if sponsored). Less things to maintain for us
(Jenkins is a beast).
1 - 100 of 809 matches
Mail list logo
