django www vs non-www issue with middleware authentication - django

I have been having inconsistent behavior with my Django app.
If I login with no www, and then prepend www, it's not authenticated, and all the combinations thereof. (www.mydomain.com and mydomain.com like different sites in terms of auth)
If the authentication code is important, I wrote a middleware based on the tutorial here: http://onecreativeblog.com/post/59051248/django-login-required-middleware
So far I have fixed the issue forcing the appending of www, using PREPEND_WWW = True, but I would still like to understand the issue;)
Does anyone have an idea of what may be going on?
Thanks in advance!

What Zaha Zorg said: Cookies from Django won't work for both a prepended www and non-www domain by default.
However, the deeper issue here is that you're allowing both www and non-www domains of your site to serve identical content. Besides the obvious SEO consequences of having traffic split between the two, you run into issues like these. The proper way to handle this is to redirect all traffic from one to the other (whichever you prefer). The PREPEND_WWW setting you found works perfectly for this. For the opposite (forcing all traffic to non-www), it's recommended to just do a re-write at the server configuration level, such as Apache or Nginx.

You need to look at https://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#session-cookie-domain
SESSION_COOKIE_DOMAIN
Default: None
The domain to use for session cookies. Set this to a string such as ".lawrence.com" for cross-domain cookies, or use None for a standard domain cookie. See the How to use sessions.

Could it be that cookies depend on the hostname of the server ? This could explain why both domain names are considered different.

Related

Getting url errors after deployment

Hello I have a django project with the domain www.itucampus.com, I owned the domain from godaddy and forwarded itucampus.com to www.itucampus.com I hosted it on pythonanywhere.com. I also forced http to https. My problem now is sometimes I could reach my webpage and sometimes not and now I found which urls are working and which not.
itucampus.com www.itucampus.com https://www.itucampus.com are working
but
https://itucampus.com http://itucampus.com http://www.itucampus.com are not working and I am getting the error to many redirects.
Could you please help me
GoDaddy doesn't support HTTPS-based redirects, so if you want https://itucampus.com to work, you'll need to use a different service for your redirects. NakedSSL is a free one that should work well.

HTTPS equivalent of Django's HttpResponse

For some reason I am in need of a views.py that returns only some text. Normally, i'd use HttpResponse("text") for this. However, In this case I require the text to be send over https, to counter the inevitable mixed content warning.
What is the simplest way of sending pure text via django(1.7.11) over https?
Django in the relevant docs of httprequest.build_absolute_uri reads:
Mixing HTTP and HTTPS on the same site is discouraged, therefore
build_absolute_uri() will always generate an absolute URI with the
same scheme the current request has. If you need to redirect users to
HTTPS, it’s best to let your Web server redirect all HTTP traffic to
HTTPS.
The docs make clear that
the method of communication is entirely the responsibility of the server
as Daniel Roseman commented.
My prefered choice is to force https throughout a site, however it is possible to do it only for a certain page.
The above can be achieved by either:
Upgrading to a secure and supported release of Django where the use of SECURE_SSL_REDIRECT and SecurityMiddleware will redirect all traffic to SSL
Asking your host provider an advice on how could this be implemented in their servers
Using the apache config files.
Using .htaccess to redirect a single page.
There are also other -off the road- hackish solutions like a snippet which can be used with a decorator in urls.py to force https, or a custom middleware that redirects certain urls to https.
I've run into the mixed content problems as well. From my experience, you simply can't use the HttpResponse objects without running into trouble. I was never totally sure though and eventually found a way "around" it.
My solution for it was to use the JsonResponse object instead, to return JSON strings, kind of a work-around with the views returning something like:
mytext = 'stuff blablabla'
return JsonResponse({'response_text': mytext})
Which is super easy to parse, and OK with HTTPS.
Maybe not what you're looking for, but I hope it helps you find your way.

Consistent user authorization across url with/without www

I need to clarify a fundamental concept (beginner here).
In a Django web app I maintain, I notice that if one logs in via going to example.com, they remain logged out on www.example.com (and can then go on to create a clone account).
1) Why does this happen?
2) What's the standard practice to iron out this issue? I.e., give one consistent experience across www and no-www.
In case the answer is as basic as just a redirection, I could use some pointers and an illustrative example there too - I'm using nginx reverse proxy with gunicorn.
1 ) Django cookies do not work for same with a prepended www and non-www domain by default.Django considers it as a different sessions.
2) The PREPEND_WWW setting you can set to redirect your xyz.com to www.xyz.com.
PREPEND_WWW = True
or if you need same cookie to both of the sites you can use session_cookie_domain,
SESSION_COOKIE_DOMAIN = ".yoursite.com"

Flask - User logged out when switching to www.*

I'm encountering a strange behavior, and I'm not really sure if it is framework-related or not.
Anyway, for my Flask project I'm using flask-login to manage user authentication.
I noticed that when I'm logging in from domain.com and then I'm switching to www.domain.com, the user appears to be logged out.
If I'm switching back to domain.com the user appears to be logged in (as expected).
This behavior doesn't go both ways, which means that logging in on www.domain.com will keep me logged in on domain.com too.
I'm not sure if it's an issue with flask-login and how it sets the session cookies or if it's related with how cookies work and so on.
Maybe you could help me out on this one :)
I believe you have to set the domain on the cookie to be .domain.com instead of domain.com for the cookie to be available to all subdomains. See this StackOverflow Question for more details!
You need to include the following line to your config file.
http://flask.pocoo.org/docs/0.12/config/
SESSION_COOKIE_DOMAIN = '.domain.com'

"URL with WWW and URL without WWW" -Is there any difference between them?

i have noticed one things , when some website are opened in any browser then in URL bar some are like
http://www.something.com
where some are like
http://something.com
here www is missing. Same things is happening with my blog url
if i write in URL bar as
http://www.shareprogrammingtips.com/
then it automatic converted in
http://shareprogrammingtips.com/
i am not getting why this happening ? is there any difference url with www and url without www ?
Edit:
one more thing i have notice is that url with www take longer time to open website then url without www takes..!
It does not matter if you have www in the URL or not, as long as you use the same URL always. This must be happening probably because your server is set-up to redirect the http://www.shareprogrammingtips.com/ to http://shareprogrammingtips.com/.
This will make sure that all the pages will always come to http://shareprogrammingtips.com/ and also search engines would index your site as http://shareprogrammingtips.com/. If your site is accessible from both http://www.shareprogrammingtips.com/ and http://shareprogrammingtips.com/ then the search engines would index both versions of your site, but the page rank of your site will be divided between these 2 versions as for search engines both these sites are different sites.
In the past, every URL required the www. prefix (i.e. www.hello.com). Nowadays we have naked domains which don't require this prefix (i.e. hello.com). We still have many domains with the www. prefix for legacy reasons.
When a company wants to buy a domain name, they can buy it either with or without the prefix, or get both (for example, buy the naked domain and set-up the same domain with the www. prefix as sub-domain) and configure both to load the same website. There are technical reasons to chosing a domain with a www. prefix (allows for certain cookie blocking polices) or a naked domain (shorter url).
Usually, one of the two will be the canonical (real) domain, while the other will only redirect to the real domain. This redirect causes a delay but it's there for a reason.
If you code this redirect the right way, search engines will understand that both are the same website. Otherwise if you skip the redirect and point both domains to your files directly, search engines will think they are separate websites which will hurt your SEO (Search Engine Optimization).