I am trying to login to the admin panel of a Django application via another server (say 123.123.123.123). I have a ssh tunnel open like ssh -L 3000:my.website.com:443 user#123.123.123.123. I can then go to https://localhost:3000/admin/login/ and see the login page for the Django admin of the server running on my.website.com. Whatever credentials I put in, results in a HTTP 403 'CSRF verification failed. Request aborted.` error page.
I do not get this error when going directly to my.website.com/admin/login/. What settings might help to allow login via an SSH tunnel? I have already tried adding 'localhost' to ALLOWED_HOSTS. The CSRF cookies are secure (only available via HTTPS, which I'm always using) and have the HTTPOnly flag set.
Django will see that you're trying to access my.website.com domain and it will send back to you cookie for that domain.
But your browser is actually accessing localhost domain, so cookies for my.website.com won't be valid for it and browser won't send them back to Django server.
One way to fix it is to point my.website.com to 127.0.0.1 using /etc/hosts, change your tunnel port to 443 and connect to my.website.com instead.
Another approach is to set any server in between you and your django server that will rewrite cookies and other paths from one domain to another.
Related
I was trying to implement 'Securing Django Admin login with OTP', however I can't login into the admin panel now. I removed the app from everywhere but still doesn't work. Any solution for this?
[05/Feb/2021 21:39:49] code 400, message Bad request version ('î\x9el\x00$\x13\x01\x13\x03\x13\x02À+À/̨̩À,À0À')
[05/Feb/2021 21:39:49] You're accessing the development server over HTTPS, but it only supports HTTP.
If you are on development version you cant use https connection on your localhost so just turn your URL to http and error will be disappear.
ex:
https://localhost:8000
or
https://127.0.0.1:8000
just turn it to
http://localhost:8000
or
http://127.0.0.1:8000
also may be at 127.0.0.1:8000
So I created a simple "social media website" where by using API I GET data from a database and I can also POST to create a social media post after I register and log in.
On my localhost it all works well. I can register, login, then write a social media post and it displays on the screen.
However, when I use Heroku, GET API works fine, but after I log in (and I am sure I am logged in as I can log in on admin), I cannot write anything on my website. In my IDE I get: Forbidden: /api/posts/action/
In the network page I can see this:
Request URL: http://localhost:8000/api/posts/action/
Request Method: POST
Status Code: 403 Forbidden
Remote Address: 127.0.0.1:8000
Referrer Policy: no-referrer-when-downgrade
Any idea where should I look for an error? If there is any code I should send, let me know. Thank you!
Your server's domain in Heroku shouldn't be localhost:8000
You need to use the correct domain/IP address, and remember to put the domain/IP address in ALLOWED_HOSTS in the setting file.
If you don't set up a custom domain, then the default domain should be like:
https://<dyno name>.herokuapps.com
We are running liferay behind haproxy.
While we were running liferay independently we were able to login without problems. However after introduction haproxy with ssl termination users experienced a weird behaviour. After restart of liferay no user is able login and there are no error messages in the log files.
Once user try to login, login form is send with filled data to the server and user is redirected back to welcome page and
No error in logs.
Cookies seems to be properly set.
Moreover we find out that once we clear the browser cache or open page in private mode users are able to login.
We tried also to clear only the browser cookies, but it doesn't help.
Can you please advice why this happens or explain such a behaviour?
Thanks.
haproxy config
frontend lb-fe-https-env
bind 10.0.0.0:443 ssl crt /etc/haproxy/ssl/dev.pem
reqadd X-Forwarded-Proto:\ https
acl host_portal_dev hdr(host) -i www-dev.dev1.sk
acl host_content_dev hdr(host) -i content-dev.dev1.sk
use_backend be_content_dev if host_content_dev
use_backend be_portal_dev if host_portal_dev
backend be_portal_dev
redirect scheme https if !{ ssl_fc }
balance roundrobin
cookie JSESSIONID prefix indirect nocache
option httpclose
option forwardfor
server dev1 dev1.portal.com:80 check cookie dev1
liferay portal-ext.properties
web.server.protocol=https
Ok, than sorry for post. Anyway if somebody will face similar issue, it was caused by haproxy configuration. Once we disabled this line it works fine.
cookie JSESSIONID prefix indirect nocache
I created a cookie in a java filter and added back to the response
response.addCookie()
before returning to the client node.js application. This web application is accessed using a localhost URL in the browser. After reading about cookie domain issue while using 'localhost', i did not set any domain or path in the cookie, while creating it.
Now the Chrome or Firefox browsers don't show-up the cookie in the browser. All my URLs are http://localhost but, each page having different path.
Step 1: During a request to http://localhost/app/login cookie is created and set in the response
Step 2: When the page loads after response, no cookies are shown in Chrome
Step 3: During the next request http://localhost/app/customer the previously created cookie is not recieved when trying request.getCookies().
Step 4: Before returning back to client application, a cookie is created
Step 5: Now the cookie created in Step 4 is shown in Chrome
Step 6: The next request is also sent to http://localhost/app/customer , now the cookie created in step 4 is recieved in the server as well
If cookie creation for localhost is an issue, how does it work for Steps 4-6 only ?
How can i make the created cookie available to all paths under the
localhost domain ? I tried using cookie.addPath("/") but, no change.
Note: Due to admin privilege issues in my development machine, i am not able to set-up a domain name to my localhost IP in etc/hosts file.
In your Java server, you should call cookie.setPath("/") before adding it to response.
Such cookie will match all request URIs. It's a pity that it is not the default behavior.
I have a more detailed explanation of cookie path here - http://bayou.io/release/0.9/javadoc/bayou/http/Cookie.html#path
Not sure path is the issue. Path does not affect whether a cookie is created; it only determines whether it is presented. If cookies aren't showing up in the browser's cookie jar they are being rejected for some reason other than path.
Chrome will not accept cookies for localhost because it does not accept cookies in the top level domain. The domain in the URL has to have a dot in it somewhere. So you could either add a hosts entry (recommended) or just trying using 127.0.0.1 instead of localhost.
Also, none of this will work if the cookie is marked as secure or is being set with a domain attribute. If either of those is the case, you MUST use a hosts entry instead of localhost or 127.0.0.1.
I want to let the same user session span across:
site.com
sub1.site.com
sub2.site.com
I got this to work in production by setting SESSION_COOKIE_DOMAIN to ".site.com", but it doesn't work for me on localhost/dev servers. How do you get it to work for localhost sub-domains? When I change the SESSION_COOKIE_DOMAIN on the dev server to the production website domain or ".localhost", django auth logins completely stop working (I'm unable to ever login, no cookie is created on localhost).
I think I got a workaround solution, but couldn't use localhost. I could only get it working for a test ".com" domain that maps to 127.0.0.1.
In my /etc/hosts file (on OSX:)
127.0.0.1 test.com
127.0.0.1 sub1.test.com
127.0.0.1 sub2.test.com
Then on my development settings.py:
SESSION_COOKIE_DOMAIN=".test.com"
I could not get this working with plain "localhost", it seemed I needed the ".com" string in there to get it working. So then I could login and have cross subdomain auth cookies using sub1.test.com:8000 and sub2.test.com:8000 in my browser.