I've just installed my app on a new server to test something out. Setup all went smoothly, app is running fine with a local mysql database behind it which is fully synced up. The only problem is I can't log in.
I've tried logging in via my frontend, and via the admin. For both, if I enter incorrect details it shows an error message. If I enter correct details it doesn't, but still throws me back to the login page.
There is nothing in the logs to suggest what's going on, all I get in a runserver log is something like:
[26/Jun/2013 15:09:31] "POST /account/login/ HTTP/1.0" 302 0
[26/Jun/2013 15:09:31] "GET /dashboard/ HTTP/1.0" 302 0
[26/Jun/2013 15:09:31] "GET /account/login/?next=/dashboard/ HTTP/1.0" 200 2537
I'm clearly logging in ok, being redirected to the dashboard, then bounced straight back to login.
I'm stumped as to where to start looking to debug this problem. The same setup is running fine elsewhere. Can anyone give me any clues as to where to start looking?
You might check the value of SESSION_COOKIE_SECURE. If set to True, the admin login form will simply redirect to itself. Also check that SESSION_COOKIE_DOMAIN is correct. I don't know how many times I've done this inadvertently in development :)
Related
I developed a chatbot with Python and flask, created an environment in ubuntu, and saved all the files in it.
after going to my website, I have to enter a question in the input bar and it has to give me a response.
Instead, it is displaying the below error in ubuntu when I enter a question and click on the send button.
"GET /static/jquery.min.js HTTP/1.1" 404 -
my website:
website image
please help me with my error
I'm trying to connect an Android device to my ObtainAuthToken endpoint from the django-rest-framework.
If I just call it with http://localhost/api-token-auth it works fine:
[21/Dec/2017 16:04:34] "POST /api-token-auth HTTP/1.1" 400 68
But if I change that to http://192.168.1.4/api-token-auth my dev server throws me a 404, like so:
[21/Dec/2017 16:05:00] "POST /api-token-auth HTTP/1.1" 404 0
I've tried adding my IP number 192.168.1.4 to ALLOWED_HOSTS but no dice. Trying to Google this issue just brings up a bunch of unrelated stuff.
Anyone knows what might be causing this?
I had a similar issue which I resolved by running the Django project on 0.0.0.0 rather than localhost.
So, I'm trying to clean up my artifactory which runs on tomcat.
I've written a script that give me what I want.
However, when I do a requests.delete() and look in the access logs, I see a GET request for the used URL, and nothing is deleted.
Code:
import requests
username="admin"
password="SomeSecurePassword"
r = requests.delete('http://artifactory.company.com/artifactory/api/storage/libs-release-local/my/path/to/delete/0.1.62', auth = (username, password))
Log:
10.10.5.200 - - [07/Apr/2017:16:44:28 +0200] "GET /artifactory/api/storage/libs-release-local/my/path/to/delete/0.1.62
HTTP/1.1" 200 579
I suspect either a tomcat or an artifactory configuration has to be changed, but I don't know where to start looking.
Google didn't turn anything up off the bat for either artifactory or Python.
The delete item REST API is using the following request format:
DELETE http://artifactory.company.com/artifactory/libs-release-local/my/path/to/delete/0.1.62
Please note you do not need /api/storage as part of request URL.
How do I prevent access to my Jetty server from unwanted URLs
10.34.6.67 - - [20/Jan/2015:13:04:05 +0000] "GET /pulse?authon&user=BB493827B64FD8B696FD0B600FA05429&url_heartbeat=1,0,156,156,0&db_conn=1,0,0,0,0 HTTP/1.1" 404 283
In order to determine if a requested URL is valid or not, the connection still needs to occur, and the request still needs to be sent.
The access log line you pasted shows that Jetty returned 404 (not found) for it.
Looks like it did the job with no further effort on your part.
I have a CSS code that generates http 304:
[08/Nov/2011 15:22:07] "GET /site_media/logo1.gif HTTP/1.1" 304 0
How can I get a workaround using the Django test server? Any clues?
Best Regards,
The 304 code is not an error. You don't need a workaround. It simply means that the static file has not changed since your browser last accessed it
For more information see the Wikipedia explanation of 3xx status codes.
If you're getting 304 with files you did change, you can force reloading in your browser by checking "Disable cache" in your browser's dev tools (on Chrome/ium, right click on webpage -> inspect element -> go to network tab -> disable cache)