Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

2019-08-07 Thread Aldian Fazrihady
What prevents the change to the API endpoints so it will have language
prefix as well?

On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Yes, I think this change makes sense, assuming no unexpected difficulties
> arise in the implementation.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
>
> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
> 1.3 and I’ve recently come across and issue that’s been bothering me in
> multiple projects that I’m working on.
>
> Localization middleware ignores the accept language header if ANY url
> pattern exists that is i18n prefixed regardless of the current URL of the
> request.
>
> So the problem is the following: I have some URLs that are prefixed, and a
> lot that are not (such as all of the API endpoints). I sometimes need to
> return some translated strings in the API as well and for that I rely on
> the accept-language header. However in the middleware it is ignored because
> an unrelated part of the project has an i18n prefixed url pattern.
>
> Another way to look at the problem is this:
>
> Let’s say I have a SPA that uses i18n on its API endpoints and you rely on
> accept-language to serve the responses in the correct locale. I then decide
> to add a new app to your django project - a sales page. Instead of relying
> on accept-language I wish to have i18n prefixed URLs (maybe for SEO reasons
> or whatever). Suddenly the behaviour of the API changes even though I’ve
> made changes to an entirely different part of the project.
>
> Would it not make more sense for the middleware to check if the current
> URL pattern (the one that the request URL resolves to) is prefixed or not.
>
> The way I see it, this should be changed:
>
> i18n_patterns_used, prefixed_default_language =
> is_language_prefix_patterns_used(urlconf)
>
> Instead of checking the entire urlconf it should only check the current
> request URL and see if it resolves to a pattern that is i18n prefixed.
>
> To get around this I need to use a custom localization firmware in a lot
> of my projects. I would like to hear the devs’ opinion regarding this.
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org?utm_medium=email&utm_source=footer>
> .
>


-- 
Regards,

Aldian Fazrihady
http://aldianfazrihady.com

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN7EoAa4tC-dPBFHj-_kMyAUv67sQRFPA-V98mRyTjaYcYvcMA%40mail.gmail.com.


Re: Error websocket 404

2019-07-11 Thread Aldian Fazrihady
Why there is http in this line:
> proxy_pass http://unix:/.../daphne.sock;

Which one do you want to use,  http or unix socket?

On Thu, Jul 11, 2019 at 1:42 PM Fatemeh Ahmadzadeh <
f.ahmadzadeh...@gmail.com> wrote:

> Hi my  friends
> I create daphne.sock for websocket and gunicorn.sock for http request ,
> two ASGI and WSGI is activated
>
>
> python manage.py runworker is excellent and dont have any Errors
>
>
>
>  nginx.conf proxy_pass equals to unixes. but have this errors according to
> this
>
> server{
>
> listen 80;
>
> server_name 185.252.11.11 domain.com;
>
>
>
>
>
> location / {
>
> proxy_set_header Host $http_host;
>
> proxy_set_header X-Real-IP $remote_addr;
>
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
> proxy_set_header X-Forwarded-Proto $scheme;
>
> proxy_redirect off;
>
> proxy_pass http://../gunicorn.sock;
>
> }
>
> location /static/ {
>
> root
> /home/Farzand-user/Farazan_Parvari_Project/Farzand_Parvar/Farazan_Parvari_Project;
>
> }
>
>
>
> location /ws/ {
>
>
>
> proxy_buffers 8 32k;
>
> proxy_buffer_size 64k;
>
> proxy_redirect off;
>
> proxy_http_version 1.1;
>
> proxy_set_header Upgrade $http_upgrade;
>
> proxy_set_header Connection "upgrade";
>
> proxy_read_timeout 86400;
>
> proxy_pass http://unix:/.../daphne.sock;
>
> proxy_set_header   Host $host;
>
> proxy_set_header   X-Real-IP $remote_addr;
>
> proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
>
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
> proxy_set_header X-Forwarded-Host $server_name;
>
>
>
>
>
>
>
> }
>
>
> }
>
>
> according to this page
>
>   https://avilpage.com/2018/05/deploying-scaling-django-channels.html
>
> http://masnun.rocks/2016/11/02/deploying-django-channels-using-daphne/
> <http://www.google.com/url?q=http%3A%2F%2Fmasnun.rocks%2F2016%2F11%2F02%2Fdeploying-django-channels-using-daphne%2F&sa=D&sntz=1&usg=AFQjCNEaeciqSaEn51NpmJu2n4svRm4B6w>
> the HTTP request is wll but I have Errors in websocket  in console WebSocket
> connection to 'ws://domain/ws/' failed: Error during WebSocket handshake:
> Unexpected response code: 404
>
> server is centos with directadmin , nginx 1.15
>
>
>
> --
> 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...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5e29f063-5760-49ce-916c-303a6eec7a0f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/5e29f063-5760-49ce-916c-303a6eec7a0f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Regards,

Aldian Fazrihady
http://aldianfazrihady.com

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN7EoAa9qdSc8wYV-wHCwLbqGFDfc2XoZLfsOtxOXys4HDgdWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Enable SESSION_COOKIE_SECURE by Default

2019-04-03 Thread Aldian Fazrihady
Hi Carlton,

Many production systems, including mine, are using HTTPS, which effectively
blocks the capability of attackers from sniffing other people's cookies.

Regards,

Aldian Fazrihady

On Wed, Apr 3, 2019 at 4:02 PM Carlton Gibson 
wrote:

> Hi all.
>
> https://code.djangoproject.com/ticket/30314
>
> >  Per the documentation, "Leaving this setting off isn’t a good idea
> because an attacker could capture an unencrypted session cookie with a
> packet sniffer and use the cookie to hijack the user’s session."
> >
> > If it's not a good idea for this setting to be off, why is it off by
> default? Seems backwards to me.
>
> This looks right to me. A small breaking change for 3.0 would seem
> reasonable. So I'm going to Accept this.
>
> BUT this has been this way forever
> <https://github.com/django/django/commit/45be33a6327bccae60319982254ee62f65bea11e>
>  so
> I just wanted to check if there were any overriding *Whys*?
>
> Thanks.
> Carlton
>
> --
> 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...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e67ee6a2-751e-4b24-9d72-6c746a8c0178%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/e67ee6a2-751e-4b24-9d72-6c746a8c0178%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN7EoAZD5zYSQNqb13sJiaLsRNyFZhE9YREW%2B4hjUrC-TQp-HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.