ing a cookie,
and why, but the GDPR does not mandate it for this type of cookie.
--
Curtis
On Fri, 9 Aug 2024, at 12:35, אורי wrote:
> Hi,
>
> Django uses cookies at least for authentication / login. How does Django
> handle the European Union legal requirements related to u
I think if you give it an
afternoon's digging you could add an option to the django core serializers to
list non-field attributes to include.
--
Curtis
>
> On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
>> __
>> Hi Mike,
>>
>> On Fri, 4 A
your code if you put "state" instead of "state_id" in the field
list?
--
Curtis
--
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 recei
Does the Forum allow me to get email notifications / summaries?
If not, it will mean I disconnect with that part of the community.
--
Curtis
On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com
Django 2.1. All current
> browsers seem to have supported it since 2019. Is it time for us to remove
> the CSRF Middleware from the default settings template file?
Are you implying that all CSRF attacks protected by Django's current machinery
are entirely mitigated by SameSite=L
ned a function that is successfully
> reading the original - changed all instances of tablename to Vtablename. AND
> it WORKS.
>
> Now, with the *Year *column, i can now much more easily use and understand my
> SQL filters when parsing a date-time column.
>
> ...so, is the
om/blog/custom-relationships-in-django) however, that's
a rather specific case.
I think it would be a good thing for progress on this issue to happen.
You might also want to check the ticket history for any work on multi-value
keys.
--
Curtis
--
You received this message because you
I recently did a bit of an audit of "settings types" whilst preparing for an
overhaul of django-classy-settings.
I found you could cover a majority of the common config types if you could
somehow parse from an environ string the following (which closely aligns with
django-environ):
+ str
+ int
FWIW +1 from me!
--
C
On Thu, 6 Oct 2022, at 14:11, Aaron Smith wrote:
> It sounds like there is little support for this being the default. But I'd
> like to propose something that might satisfy the different concerns:
>
> 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintain
On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote:
> Why doesn't Django validate Models on save()?
The short answer is: backwards compatibility.
Model level validation hasn't always been a thing, with Django initially
depending primarily on Form validation.
Since it hadn't _always_ been there, i
Note: there is nothing to stop you from using `logging.DEBUG` if you prefer.
--
Curtis
--
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 fr
k` allows more generic query construction.
This is used, for example, in the generic views.
>
> From SQL point of view it doesn't matter because it is always:
> SELECT * FROM car WHERE id=1
>
> It am not sure if using "pk" gives value to users. Field "pk" is n
c and marshmallow, have begun
filling this space.
One place we could help everyone is by providing a JSON request-body parsing
utility.
--
Curtis
On Thu, 16 Sep 2021, at 10:58, Benny wrote:
> There are serializers and dictionaries built into the Django models system
> that I’ve had ze
size below which it's deemed not worth the effort to try to compress.
--
Curtis
On Tue, 15 Jun 2021, at 04:49, Illia Volochii wrote:
> Hi all,
>
> There is `GZipMiddleware` that compresses response bodies using gzip.
> https://github.com/django/django/blob/main/django/middleware
ser record.
This would mean then we normalise the idea of separating credentials, and
having multiple sets for a single user; Each auth backend would know to check
its own set, be it (username, password), or Twitter oauth token, or whatever.
--
Curtis
On Fri, 9 Apr 2021, at 12:50, NIKHIL MUDDAMS
ap with that is a matter
of including the CSS file, and adding the classes.
--
Curtis
On Mon, 22 Mar 2021, at 12:50, manasdeep borole wrote:
> Thanks
> But it seems there is no support for bootstrap (at least not directly)
> Or may be I am missing something
> Please feel free
On Fri, 29 Jan 2021, at 19:18, Aztec Rabbit wrote:
> Curtis - This is nested block right? what i want is like tag include (can be
> called more than once) but with children.
Correct. And that's more or less what nested block does;
The difference from include is sniplates takes a t
I recall a discussion some time about about adding a setting to control which
field to use for the default PK... seems there's some overlap here.
--
C
On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote:
> tl;dr: Introduce new field types to handle auto-incremented ID fields, change
> the P
I second this; I would have moved to having auth.User be abstract, and force
projects to create their own _always_, except (a) it breaks a lot of history,
and (b) it breaks the "ready to go out of the box" nature.
It's a small cost at the start of your project, that avoids problems for a
sizabl
I did something like this in django-sniplates
https://sniplates.readthedocs.io/en/latest/tags.html#the-nested-widget-tag
--
C
On Thu, 28 Jan 2021, at 17:33, Aztec Rabbit wrote:
> Hi,
>
> I think template tag like in JSX is very useful, for example:
>
> > card.html
>
>
> {{ title }}
> {{
vidual projects could opt to
use.
--
Curtis
--
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 django-developers
medium it needs escaping
for -- e.g. HTML needs different escaping than URLs.
--
Curtis
On Tue, 18 Aug 2020, at 18:35, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself) wrote:
> Currently, when you order a security audit on a Django project from any of
&
Interesting ideas... and looks similar to some of the features I put into
Sniplates: https://sniplates.readthedocs.io/en/latest/
If you like we can work on adding this to sniplates, if it's not accepted into
core.
--
Curtis
On Mon, 17 Aug 2020, at 19:05, Jure Erznožnik wrote:
&g
t; is compared to a "whitelist".
Same argument was involved in changing the terminology we used for replicated
databases. It made sense then, it makes sense now.
--
Curtis
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contribut
On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote:
> > If Django were to provide a solid API for parsing Accept headers [not as
> > easy as it sounds] and selecting a preferred response type [based on accept
> > preference weights] ... would that take care of the bulk of "content
> > negotiation
w progressing past the boiler plate [verifying the target
object exists, etc], doing its "work", then checking what response form to use,
and branching there.
--
Curtis
On Wed, 20 Nov 2019, at 21:04, Jure Erznožnik wrote:
> Agree.
> I understood that the discussion already turn
ot enforce an overly restrictive world view.
I, for one, would be very interested to see more details here on what changes
you propose. Then, at least, we can keep a mailing-list history record of the
discussion.
--
Curtis
On Tue, 16 Jul 2019, at 12:22, Jonathon Sumner wrote:
> Hi all,
>
> S
g any
Python packages globally. Leave system python for the system :)
--
Curtis
On Tue, 16 Jul 2019, at 10:37, Ehigie Aito wrote:
> Ok, before I start let me apologize.
> It seems I am the proverbial boy who cried wolf as I have discovered where
> the source of the problem.
> I hope my
e that this change has happened.
As I said earlier, I think there is a change in how Python 3.8 works that is
causing those checks to fail.
--
C
>
> On Mon, 15 Jul 2019, 13:07 Curtis Maloney, wrote:
>> __
>> I think you're making an assumption about the cause of the proble
I think you're making an assumption about the cause of the problem, without
evidence.
Yes, there's an issue shown in that traceback related to middleware, but I've
not seen yet why you've concluded it's creating a settings.py with
MIDDLEWARE_CLASSES.
I think the problem is more likely some cha
On Mon, 15 Jul 2019, at 21:36, Ehigie Aito wrote:
> Like I said, in older versions of Django, that variable used to be named
> MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django
> 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named
> MIDDLEWARE_CLASSES which
On Mon, 15 Jul 2019, at 21:23, Curtis Maloney wrote:
> First for everyone reading, it's important to note that Python 3.8 hasn't
> been released yet.
To elaborate on this point - it's _close_ to release, so it's valuable to see
how Django behaves with it.
--
C
--
tting?
Could you also provide details on how manage.py fails? Perhaps a traceback?
--
Curtis
On Mon, 15 Jul 2019, at 20:57, Ehigie Aito wrote:
> Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable
> in the (link: http://settings.py) settings.py <https://t.co/
x27;s most likely there as a legacy state, in order to reduce the
burden of upgrading.
I do agree it would be better if we abide by our own recommendations.
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django it
hese settings in settings.py
I would definitely *allow* namespace clashes, as explained above. Like
in partial classes. A "Textprinter" plugin could have 3rdparty
sub-plugins, which could use the same namespace (HTMLProviderPlugin,
MarkdownProviderPlugin etc.)
Yes, I did consider this
ts entry points a
reference to its settings declaration. This way, all 3rd party settings
can be gathered, vetted, and applied before having to scan the
INSTALLED_APPS list.
Now what we'll need is a way to avoid namespace clashes, and a
dev-friendly way to update these settings in setti
lutely yes!
Thanks for you opinion and guidance,
--
Curtis
--
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 django-d
it (as well as
demonstrated in this list) there are cases where its style makes code
significantly harder to read.
And IMHO, the sole purpose of a consistent style (and thus a style
guide) is to reduce the cognitive load of humans parsing code.
--
Curtis
--
You received this message because you are su
I cannot find emoji enough to express how much I appreciate the work
you've put into this :)
--
Curtis
On 4/25/19 6:50 AM, Andrew Godwin wrote:
Hi everyone,
Just wanted to drop a note and say that the first pull request in the
series needed to enable async in Django is now ready for r
e you save a model, and enforce catching
validation exceptions there].
Models _support_ validation, but don't _enforce_ it.
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubsc
ot;Foo Bar" (`key.replace("_",
" ").title()`)
For reference, this is what my project does ( labeled-enums:
https://pypi.org/project/labeled-enum/ )
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Cont
re clearly know what you're asking for.
--
Curtis
--
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 e
module with a lot of
strings wrapped across lines. black opted to push them onto the same
line, but NOT to merge them. This is because in Python prior to 3.7, it
would have altered the generated AST - one of the guides black uses)
--
Curtis
--
You received this message because you are s
ot;legacy" read "philosophical choices" :)
--
Curtis
--
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
mple and common enough to add to
django as batteries-included built-in?
Alternatively, I recall some time in the past I may have written a
"strings" template filter library simply to provide string methods as
filters...
--
Curtis
--
You received this message because you are subscr
t of
Django itself.
Is there a reason why your project could not remain a 3rd party library?
This would allow it to develop and release at a pace independently of
Django's release cadence.
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Dj
k it would be controversial to add the rel="noreferrer" part
to the docs no matter what choice we make about the other functionality.
--
Curtis
On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen
wrote:
Just wanted to chime in and say we also experi
wever there are alternatives.
However, by explicitly listing DRF, it might give the impression it's
the "blessed" solution by Django...
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" g
at talks HTTP(S)."
Since Django doesn't care what the client is, so long as it talks HTTP...
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this grou
On 12/14/18 5:30 AM, Avi Garg wrote:
Does Django have an IRC channel? I am unable to join it if so...
There is #django on the Freenode network.
To join it you will need to create an account on their network - see
https://freenode.net/ for more details.
--
Curtis
--
You received this
tation recommends
indexing on the ORDERing fields, where possible.
--
Curtis
--
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
solution, but it's far more likely to get
people to give input than asking for discussion.
[No, I'm not just wrapping up "patches welcome" - this is a general
observation in life. It's just more openly recognised in OSS :) ]
--
Curtis
--
You received this message b
directly is fine, so long as it's not a security
related issue.
The Django Fellows do an excellent job of curating and addressing
issues, and the Trac helps keep a coherent history of discussion of the bug.
Just go https://code.djangoproject.com/ and follow the instructions :)
--
Curtis
-
ficient than the 1+(P x N-rows) it would otherwise
be [or worse!]
--
Curtis
--
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,
nclude that field.
Hope this helps some.
--
Curtis
--
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 django-develope
eference, and (c) content type.
--
Curtis
--
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 django-developers+unsub
make a mistake? We don't want to trounce real data."
--
Curtis
--
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,
_execute_create_test_db and when it will succeed / raise exception.
--
Curtis
--
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
In general this sounds like a tremendously useful tool... I'm caused to
wonder, however... what, if any, are the performance impacts?
--
Curtis
On 08/21/2018 08:10 AM, charettes wrote:
Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been wo
es would be far less work for everyone
involved.
You could also provide them, quite trivially, as a 3rd party app for
other people facing the same issues as you.
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to D
lower.
As is always the case with improving performance, measurement and
careful analysis are requried.
--
Curtis
--
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
On 06/05/2018 07:54 AM, Tom Forbes wrote:
Are the proposed modifications to how Django runs sensible?
I had a few random thoughts while reading your proposal:
I think getting rid of the related field references could be a big issue
here and cause a lot of headaches for existing applicatio
will no longer raise errors.
--
Curtis
2018년 5월 31일 목요일 오전 11시 41분 22초 UTC+9, oli...@kidsnote.com 님
의 말:
In the template filter system now,
spaces between augment separator and augments generate error.
For example, the following template code generates the following error
r checking algorithm over the current
one, where the validator loads the whole file into memory on
initialization (and doesn't share it between instances).
The current solution is storing the strings in a set, so membership of
strings in a set _should_ be fairly efficient.
--
Curtis
OOI have
By which I mean... hi Brenton! Great to see you being active again :)
It's great you've taken the time to do this, and the benefits are very
clear [improved security], but what are the costs?
Whilst you're at it, what is the new file size?
--
Curtis
On 03/30/2018 04:26 PM,
What sort of performance impact is this having over the existing list?
What's the additional memory load, if any?
--
Curtis
On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and
included a list of 1,000 passwords considered
so addressed in the documentation:
https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubs
On 03/17/2018 08:18 PM, Manasvi Saxena wrote:
Hello Sir,
On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote:
On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:
> Hi!
>
> Template languages are my favorite topic in programming.
Having writ
s, minimal output.
--
Curtis
--
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 django-developers+unsubscr...@googlegr
s) I copied the pattern used by
database connections.
That said, I like your idea of sharing the connection pool between threads. It
would mean at worst we'd wind up where we are.
--
Curtis
On 8 March 2018 06:53:57 GMT+11:00, Nicolas Le Manchet
wrote:
>Hello,
>
>Thanks to commit
on IRC, I think the wording here is a bit weak... "it might
be" probably ought be "it is probably".
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscrib
e app it's required to also
migrate old data into new schema.
This also happens within project-specific apps.
--
Curtis
On 02/20/2018 05:05 PM, djrobstep wrote:
Hi all,
Some thoughts on schema migrations that may interest you. By way of
background, I'm the author of migra
(htt
and ModelAdmin, as well as GCBV.
If I missed anything, I'm sure someone else will remind me.
[Also... why is it always MongoDB, instead of something with a solid
reputation of reliability and performance?]
--
Curtis
--
You received this message because you are subscribed to the G
t are generated.
I've started looking into the migrations code, and it appears the steps
are very much hard-coded [and, it appears, with much painfully learned
good reasons]...
Anyone with more familiarity with the migration machinery got input on
if this is feasible?
--
Curtis
--
You rec
e [such as clean functions] -
manages to get into the cleaned_data dict.
--
Curtis
--
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 i
So, I've taken a different approach, following Markus' idea, and added
"app_label" to Permission.
I probably still need to add a check to ensure you don't set app_label
_and_ content_type, but that can wait for now.
You can now define new app-level permissions on the app's
AppConfig.permis
On 12/31/2017 11:51 AM, Josh Smeaton wrote:
- I dislike the seetings approach of GLOBAL_PERMS and would rather see
users writing explicit data migrations.
I don't favour either setting or migration based perms, but if you're
going to go with migration based, then please also consid
On 12/31/2017 12:50 AM, Markus Holtermann wrote:
Thanks Curtis,
I had a quick look. Some thoughts (in no particular order):
- IMO a nice idea. I've attached all model independent permissions to
the user model in the past to work around the limitation.
Certainly a good one I'll r
So, after a discussion with a new user on #django today I decided to
make "permissions not bound to models" a first-class feature.
So I've written a simple patch that is in
https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1
Basically:
1. Allow Perm
missions. This will mean any
half-decent level of testing will uncover a typo in a permission name,
since you will never trigger the True state.
This would also be an argument for is_superuser to equate to "has all
the perms" instead of "has_perm always says true".
--
Cu
The 2 goals of a famework:
- protect you from the tedious things
- protect you from the dangerous things
N+1 queries would be in the 'dangerous' category, IMHO, and 'detecting
causes of N+1 queries' is in the 'tedious'.
If we can at least add some DEBUG flagged machinery to detect and warn
of
Is there any list of things we gain from dropping / adding any particular
version?
The older discussion mentions a tracking ticket, but it is empty.
--
C
On 8 August 2017 9:45:54 AM AEST, Tim Graham wrote:
>With a little more than a month to go until the Django 2.0 alpha
>(targeted
>for Septe
emove. To keep STATIC_URL (which I
rarely change) but remove STATIC_ROOT (which is different per project
and sometimes even per install) is beyond me.
Because STATIC_URL is useful always, whereas STATIC_ROOT typically only
makes sense when you deploy...
--
Curtis
--
You received thi
lates are one of the least utilised features of
Django, sadly.
It deserves more marketing :)
--
Curtis
--
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 recei
s sound fair and reasonable?
Do we care about mobile browsers?
Does Safari deserve/require special casing?
Once we can resolve this, I want to start working on revising all the
JS. But I won't start that until I know what dross I have to still drag
along.
--
Curtis
--
You received thi
On 10/06/17 22:21, Claude Paroz wrote:
Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :
Right, hence my point of having a global setting to say "the default
auto-field is ..."
I see, but this conforms to the pattern "use the same id field type for
a
f) let MySQL users opt for PositiveBigAutoField if they want...
On 10/06/17 19:40, Curtis Maloney wrote:
Right, hence my point of having a global setting to say "the default
auto-field is ..."
This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
Right, hence my point of having a global setting to say "the default
auto-field is ..."
This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to cha
ated primary key "swappable", including
>foreign keys that point to it. This sounds like a headache.
>
>I haven't thought of a possible solution since Kenneth floated this
>idea in
>#django-dev yesterday.
>
>On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis M
I know people hate settings, but what about one for auto id field type?
It would let you handle backwards compatibility, uuid, and bigint...
--
C
On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss wrote:
>I think this would be a good improvement, and I'd like to see it. I've
>been
>bitten by i
What about using inspect.getmembers ?
https://docs.python.org/3/library/inspect.html#inspect.getmembers
In other code I've also used inspect.classify_class_attrs but it seems
to be undocumented :/
If nothing else, it could be used as a guide on how to do this.
--
Curtis
On 03/06/17
e the idea of having it scan INSTALLED_APPS to allow registering
custom DB backend protocols... though I think the modern approach is
AppConfig.ready ?
--
Curtis
On 29/05/17 08:23, li...@lew21.net wrote:
There's also https://github.com/doismellburning/django12factor - and it
simplifi
iving it a go anyway :)
--
Curtis
--
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 django-developers+unsubscr...@goo
Dogfooding is a fairly strong argument, IMHO.
Especially when there's a volunteer to do the work.
--
C
On 7 May 2017 6:53:13 PM AEST, Paolo Melchiorre wrote:
>On Sun, May 7, 2017 at 9:16 AM, Florian Apolloner
> wrote:
>> On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote:
>>>
>
rowsers, but the
link it provides does nothing to explain the supported versions, and a
further "target environments matrix" link still lists IE6.
So perhaps it's time to update the FAQ, and have a discussion on what
Admin's browser support policy needs to be updated to.
--
Curtis
See? This is exactly what I told you you could expect ... to be shown
the new release process details :)
[For those playing at home, Bernhard raised this concern on IRC first,
and I recommended bringing it here. He expressed concern about being
roasted, and I predicted someone would introduce
, there are often cases when templating obscure configuration
files that they come in useful.
I believe SmileyChris had a patch to add this to DTL...
--
Curtis
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django i
>From what I can see in the rfc, it is permitted but not required.
Only a body in a 204 response is proscribed.
Any metadata (I.e. headers) are about the resource just accessed... So a
Content-Type would, IMHO, be acceptable but not essential.
On 26 December 2016 9:47:02 PM AEDT, roboslone w
My solution to the "initial password problem" is to send a password
reset token first...
And Django has this built in, handily :)
http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/
It would be very easy to use the same approach for an "invite"
registration pattern.
-
Well, I certainly agree with the intent... especially, as you say, for
LTS users who effectively cement themselves to a version for the long haul.
Might as well remind them there are security updates in things other
than OpenSSL, Java, and Django :)
--
C
On 15/11/16 09:49, Tim Graham wrote:
1 - 100 of 307 matches
Mail list logo
