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.
Related
I followed this tutorial on how to host server side generated sites on Google Cloud Buckets. The issue I am having is that the nuxt app works fine when routing internally, but when I reload a route, the site is redirected to whatever route plus a /index.html at the end.
This causes things to break, as it conflicts with Nuxt routing. I set index to be my entry point ala
gsutil web set -m index.html -e 404.html gs://my-static-assets
but it seems to assume that to be the case always. I don't have this problem using Netlify.
According to the tutorial that you're doing, you're redirected to /route/index.html because of your MainPageSuffix index, this means that when you try to access for example https://example.com/route the service look for the target https:// example.com/route/index.html.
To fix this I suggest that you include an index.html file under the subdirectory in the subdirectory of the route.
I recommend, for further info on this to check this post which has a similar issue.
I've created an Azure Static Website which works based on the Azure Blob Storage.
To be able to manage the automatic redirect from HTTP to HTTPs I created Azure CDN with Azure Verizon Premium subscription and I created an endpoint which
points to the URL of the static website. I followed the steps from this tutorial
If you hit the URL e.g.
https://blah.com/foo/
You will be automatically redirected to
https://blah.com/foo/index.html
This is because I set the Index document name to index.html in the Static website configuration panel.
What I want to achieve is to add the /index.html symbol to the very end of URL if it doesn't have an extension e.g.
https://blah.com/foo
https://blah.com/bar/foo
The expected result would be a redirect to:
https://blah.com/foo/index.html
https://blah.com/bar/foo/index.html
So my idea was to open the https://cdn.windowsazure.com/http/rules/default.aspx and try to create a new Rule; feature-> URL Redirect. In the TextBox near the Source label, I tried to specify the condition using Regex expression ^[^.]+$ which checks if the path contains a . If yes then it would mean the URL points to file with extension and the /index.html should be added to the end of URL. I think my Regex expression is wrong and should be different. Or maybe it is not the best way to achieve what I want?
Any ideas?
Cheers
So I tried almost everything and in the end, after adding this rule the Azure Static Webiste worked as expected:
Just further to this as I know it has an accepted answer but you won't need any redirect rule for index.html if you use a custom origin and use the static website's primary endpoint (will be something like .z8.web.core.windows.net/). For whatever reason, the CDN will treat that as a web server rather than a vanilla storage place.
I have a website hosted on a Google Cloud Storage bucket, following the instructions on https://cloud.google.com/storage/docs/hosting-static-website. The site works, but navigating to any subdirectory page directly, such as https://example.com/blog, will redirect me to https://example.com/blog/index.html, and sometimes this results in another redirect to my 404 page. If I start at https://example.com, and navigate elsewhere, the site works fine.
This is with the MainPageSuffix set to index.html and NotFoundPage set to 404.html.
If I navigate to a subdirectory page with a trailing slash at the end (e.g. https://example.com/blog/), the site works fine. I’ve also looked st the troubleshooting advice for 301s, and it running through the steps did not work for me.
Is there any way to enforce the trailing slash for GCS buckets as a static site? If not, how can I get around the issues I am seeing with redirects to index.html?
If your MainPageSuffix is index.html, when you try to access a subdirectory directly such as https:// example.com/blog as you indicated, the service try to look for the target object or https:// example.com/blog/index.html. Same is also true for https:// example.com/blog/ assuming no zero-byte object exists for /blog/. In case a zero byte empty object exists for /blog/, See the Troubleshooting topic for removing this zero byte object. When the zero byte object is removed the system will show https:// example.com/blog/index.html. If no such object exists the system will show an error page "404.html" if it is set for NotFoundPage.
In your case if you include an index.html file under the subdirectory /blog/ it should resolve the issue by displaying the https:// example.com/blog/index.html page in both scenarios https://example.com/blog or https://example.com/blog/. Alternatively you need to provide the full path to access any particular object within the subdirectory.
For further info on how subdirectory works see the following links.
How Subdirectories Work
From Recommended: Assigning specialty pages:
An index page (also called a webserver directory index is a file served to visitors when they request a URL that doesn't have an associated file. When you assign a MainPageSuffix, Cloud Storage looks for a file with that name whose prefix matches the URL the visitor requested.
For example, say you set the MainPageSuffix of your static website to index.html. Additionally, say you have no file named directory in your bucket www.example.com. In this situation, if a user requests the URL http://www.example.com/directory, Cloud Storage attempts to serve the file www.example.com/directory/index.html. If that file doesn't exist, Cloud Storage returns an error page.
The MainPageSuffix also controls the file served when users request the top level site. Continuing the above example, if a user requests http://www.example.com, Cloud Storage attempts to serve the file www.example.com/index.html.
If you are still experiencing any issues, please provide the breakdown of your website so that specific solution for your problem can be provided and also indicate what specific outcome you are expecting.
For info, I intentionally inserted a space after each http:// to avoid including so many links in this post.
I am writing a single page app with React for educational purposes. My React-Router v4 BrowserRouter handles client side routing correctly on CodeSandbox but not locally. In this case, the local server is the webstorm built-in devserver. HashRouter works locally but BrowserRouter does not.
Functioning properly: https://codesandbox.io/s/j71nwp9469
You are likely serving your app on the built-in webserver (localhost:63342), right? Internal web server returns 404 when using 'absolute' URLs (the ones starting with slash) as it serves files from localhost:port/project_name and not from localhost:port. That's why you have to make sure to change all URLs from absolute to the relative ones.
There is no way to set up the internal webserver to use project root as server document root. But you can configure it to use URLs like http://<host name>:<port> where the 'host name' is a name specified in hosts file, like 127.0.0.1 myhostName. See https://youtrack.jetbrains.com/issue/WEB-8988#comment=27-577559.
The solution was to understand how push state routing and the history API works. It is necessary to proxy requests through the index page when serving Single Page Applications that utilize the HTML5 History API.
The Webstorm dev server is not expected to include this feature, therefore the mention of Webstorm in this thread was a mistake.
There are multiple libraries of < 20 lines which do this for us, or it can easily be hand coded.
I'm trying to configure cubesviewer and try out the setup.
I've got the app installed running, along with cubes slicer app too.
However, when I visit the home page
http://127.0.0.1:8000/cubesviewer/
it fails popping up an error "Error occurred while accessing the data server"
Debugging with the browser console, shows a http status 403 error with the url http://localhost:8000/cubesviewer/view/list/
After some googling and reading, I figured I'll need to add rest frame auth settings. (as mentioned here.).
Now after running migrate and runserver, I get 401 error on that url.
Clearly I'm missing something with settings.py , Can somebody help me out.
I'm using the cubesviewer tag v0.10 from the github repo.
And find my settings here. http://dpaste.com/2G5VB5K
P.S: I've verified Cubes slicer works separately on its' own.
I have reproduced this. This is error may occur when you use different URL to access a website and to access related resources. For security reasons, browsers allow to access resources from exactly the same host as the page you are viewing.
Seems you are accessing the app via http://127.0.0.1:8000, but you have configured CubesViewer to tell clients to access the data backend via http://localhost:8000. While it's the same IP address, they are different strings.
Try accessing the app as http://localhost:8000.
If you deploy to a different server, you need to adjust settings. Here are the relevant configuration options, now with more comments:
# Base Cubes Server URL.
# Your Cubes Server needs to be running and listening on this URL, and it needs
# to be accessible to clients of the application.
CUBESVIEWER_CUBES_URL="http://localhost:5000"
# CubesViewer Store backend URL. It should point to this application.
# Note that this must match the URL that you use to access the application,
# otherwise you may hit security issues. If you access your server
# via http://localhost:8000, use the same here. Note that 127.0.0.1 and
# 'localhost' are different strings for this purpose. (If you wish to accept
# requests from different URLs, you may need to add CORS support).
CUBESVIEWER_BACKEND_URL="http://localhost:8000/cubesviewer"
Alternatively, you could change CUBESVIEWER_BACKEND_URL to "http://127.0.0.1:8000/cubesviewer" but I recommend you to use hostnames and not IP addresses for this.
Finally, I haven't yet tested with CORS support, but check this pull request if you wish to try that approach.