I try to follow tutorial from Udemy,Learning Django from Scratch.I have come to this point
OK,then I change DEBUG in settings file to False.After that at localhost
Not Found
The requested URL / was not found on this server.
Why?
If your question is why you are seeing different response depending on the value of DEBUG, then the answer is that when DEBUG is True, Django will present you with the stack traceback so that you can debug what is going on and fix the problem.
But when the DEBUG is false, it means that your app is live and users can access it. You don't want to show your users all the traceback of your application if some error happens.
If that's not your question, the answer is that you just don't have that path configured in your app.
Hope it helps.
It's simple: there is no rule which match the "/" (root) route.
Add one in your urls module.
See: Django 404 error-page not found
Since there is nothing after localhost:8000, it is trying to look for a url with regex "^/". Your website does not actually have that pattern. The patterns your site does have are provided in the error message "^/store", "^/accounts", etc.
If you were to type localhost:8000/store into the url, it would try and find a matching url following the patterns in the webapp following the "^/store" pattern (presumably named store) store/urls.py.
If you would like to access a page at localhost:8000, you will have to add a new pattern to the list in your root directory's urls.py file.
Related
I've been trying to add google login to my django app following this tutorial:
https://github.com/RealmTeam/django-rest-framework-social-oauth2
By following exactly the instructions, everything works fine in local.
However, when I try to replicate the same on the server, I get the following error on the redirect page of the login:
Error 400: redirect_uri_mismatch
redirect_uri: http://localhost:8000/auth/complete/google-oauth2/
What is strange to me is, in my google developer console, I have set up the correct redirect url in my app, as follows:
https://mydjangoapp.com/auth/complete/google-oauth2/
And I have also put 'mydjangoapp.com' under 'Authorised JavaScript origins'.
So my question is, why google keeps telling me that the redirect url is
http://localhost:8000/auth/complete/google-oauth2/
which is not the one I have set up in the console? Perhaps there is something obvious that I'm missing here. Thank you!
Why google keeps telling me that the redirect url is
Because your application is sending its in your code the app is running on http://localhost:8000 and if you are using a client library its probably adding the rest automatically.
http://localhost:8000/auth/complete/google-oauth2/
The redirect uri must exactly match what you are sending from your application.
You need to add
http://localhost:8000/auth/complete/google-oauth2/
Javascript origin is only needed if your code is using javascript.
This video will show you how to fix the error. Google OAuth2: How the fix redirect_uri_mismatch error. Part 2 server sided web applications.
If you want your code to send https://mydjangoapp.com then your going to have to be running it from https://mydjangoapp.com probably and you may need to figure out how to configure it so that it is running from the correct host.
I am trying to use djangocms for the first time, using https://docs.django-cms.org/en/latest/introduction/01-install.html
I did exactly as instructed above and logged in but, as soon as i log in the following error occurs...
Request Method: GET
Request URL: http://127.0.0.1:8000/en/admin/cms/page/3/change/?language=en
Raised by: cms.admin.pageadmin.change_view
page object with primary key '3' does not exist.
Could anyone help and explain what might be my problem?
It's possible that you have an old redirect in your url when trying to login. You may have since deleted the page with the id 3 which is why it cannot be found.
If you visit the following url the issue should disappear and you should now be able to navigate to any page that is show in the page list: http://127.0.0.1:8000/en/admin
This is not ColdFusion specific, but the server is ColdFusion 10 on Windows Server.
About once a day I'll get a log file of a string of missingtemplate errors, and I can't figure out if this is a typo somewhere on my part, or a user doing something, or some sort of exploration exploit.
The most recent one from last night doesn't seem like it affects the user, as by following CGI.QUERY_STRING I can see they come to the home page, hit our login_action.cfm page to log in, get into the logged in area and then again following the CGI.QUERY_STRING I can see what pages they were on by the URL variables.
The missing template target page argument is always this:
TARGETPAGE /https:/secure.domain.com/index.cfm
Which shows this for path translated and script name
PATH_TRANSLATED D:\web\site\https:\secure.domain.com\index.cfm
SCRIPT_NAME /https:/secure.domain.com/index.cfm
After she logs in I can see by the CGI dump that she is indeed logged in OK
PATH_TRANSLATED D:\web\site\https:\secure.domain.com\user\login\index.cfm
Under the query_string I'll be able to see what pages she's on with ?p=home, ?p=editaccount (URL would be index.cfm?p=home etc.)
I don't believe this is malicious, nothing is exposed to the user as far as error reporting, but nonetheless I'd like to figure out why / how this happens about once per day on this application, and understand how it does not seem to effect the user on the site yet throws these missingtemplate errors.
You may have a malformed link somewhere in your app.
Look at the referrer of the error page, then inspect that previous page on the client side (as a user).
Also look at the user agent. It could be a browser trying to pre-fetch pages - and I'm assuming one is from a malformed link.
I have my Django app. I have a redirect URL(say a 404 page) to be redirected when no other URL matches. Now if any url is called as
mysite.com/something
I am redirected to the 404 page. But
mysite/something/
works fine.
The redirection url added to the end of all:
url(r'^.*/',theview),
When I remove the redirect url from the urls.py, the problem is cleared and the above URL works (without / at the end). Why is the error?
First of all, it would be a good idea to link to your previous post and mention you are using a hack that I gave you, because (A) it's not normal setup and (B) Someone might come up with a better idea than mine
Secondly, you're seeing this behaviour because of normal url processing. See, the urls mysite.com/something and mysite.com/something/ are not the same. To match it with django's urls, the difference would be:
url(r'^something/$')
url(r'^something$')
Since the difference is so minor, when using a normal setup, after failing to find the a url without a forward slash django's common middlewere* will automatically try to add one and test it. It's only then that it would give up and forward you to a 404 page.
However, in your setup, the catch-all url prevents the second round because it does apply to the url without the forward slash. My solution? Don't worry about it. The only reason you're using this hack is because Debug=True means a debug page instead of your custom 404 page, a problem you won't be facing when moving to a production environment
*and a big thanks to #Alasdair who pointed this out in the comments
In deploying a version of the Django website I'm working on to Microsoft's Azure service, I added a page which takes a query string like
http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>
However, I was getting 404 responses to this URL. So I turned on Django's Debug flag and the page I get returned said:
Page not found (404)
Request Method: GET
Request URL: http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>?username=<some_username>&password=<some_password>
Using the `URLconf` defined in `<my_project_name>.urls`, Django tried these URL patterns, in this order:
^$
^security/ ^user/$
^account/
^admin/
^api/
The current URL, `security/user/?username=<some_username>&password=<some_password>`, didn't match any of these.
So it seems to be appending the query string onto the end of the url that already has the same query string. I have the site running on my local machine and on an iis server on my internal network which I'm using for staging before pushing to Azure. Neither of these site deployments do this, so this seems to be something specific to Azure.
Is there something I need to set in the Azure website management interface to prevent it from modifying URLs with query strings? Is there something I'm doing wrong with regards to using query strings with Azure?
In speaking to the providers of wfastcgi.py they told me it may be an issue with wfastcgi.py that is causing this problem. While they look into it they gave me a work around that fixes the issue.
Download the latest copy of wfastcgi.py from http://pytools.codeplex.com/releases
In that file find this part of the code:
if 'HTTP_X_ORIGINAL_URL' in record.params:
# We've been re-written for shared FastCGI hosting, send the original URL as the PATH_INFO.
record.params['PATH_INFO'] = record.params['HTTP_X_ORIGINAL_URL']
And add right below it (still part of the if block):
# PATH_INFO is not supposed to include the query parameters, so remove them
record.params['PATH_INFO'] = record.params['PATH_INFO'].split('?')[0]
Then, upload/deploy this modified file to the Azure site (either use the ftp to put it somewhere or add it to your site deployment. I'm deploying it so that if I need to modify it further its versioned and backed up.
In the Azure management page for the site, go to the site's configure page and change the handler mapping to point to the modified wfastcgi.py file and save the configuration.
i.e. my handler used to be the default D:\python27\scripts\wfastcgi.py. Since I deployed my modified file, the handler path is now: D:\home\site\wwwroot\wfastcgi.py
I also restarted the site, but you may not have to.
This modified script should now strip the query string from PATH_INFO, and urls with query strings should work. I'll be using this until I hear from the wfastcgi.py devs that the default wfastcgi.py file in the Python27 install has been fixed/replaced.