Anyone know how to invalidate the root document of a custom origin that use's friendly url's?
eg: example.com ?
What would be the correct Object Path to request via the AWS Create Invalidation dialog?
The documentation only refers to actual files eg: images/image1.jpg, and where it does mention folders there are never the root only images/ etc.
The leading slash is optional¹ in an invalidation request for anything other than the root, but for the root of the site, the path to invalidate should just be /.
¹ optional in the console only. When interacting with the API (including with aws-cli and the SDKs) the leading slash is required. It isn't clear why the console implicitly and invisibly adds a slash when one isn't supplied, but that's what is happenning. Best practice would be to always supply the /.
Related
I am about to move my html files from the root folder to a couple of subfolders.
The default setting my host is using is to show the trailing slash for the subfolders and no slash for the html files. If the browser requests a subfolder without trailing slash, a 301 redirect to the same folder with trailing slash is returned. The files are shown without html extension thanks to a .htaccess snippet.
I think I like the approach to distinguish the subfolders from the files. In my case the contents of the index files will be different than the ordinary files.
However, I am not as convinced as many others that duplicate content is a disaster. I cannot be sure how my websites will develop in the future and what I will think about trailing slashes and such, so an easy forward compatible strategy is therefore desirable. For that reason I am considering to abandon the 301 redirect and instead allow the browser to send urls to subfolders both with and without the trailing slash and with response 200 OK in both cases. Yes, that leads to duplicate content, but I will will keep the trailing slash on all subfolders on all internal and canonical links, so in practice, I do not think it is a disaster. And Google and Bing and others should be able to figure things out.
I have my sites on a shared server configured via directadmin and (probably) no access to other configuration files and do not know how the default setting has been accomplished. I guess I need to do something in .htaccess to change the default setting but I am not sure what.
Is there anybody who knows how to override the default setting so that I get rid of the 301 redirect in the mentioned case and instead send 200?
I found this interesting document https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryindex , but I can not interpret it, and I do not dare to do any trial and error. Hope that somebody can give me a hint.
I want Apache to blindly give the root website directory the full URL without a concern for the path. Reason being I have an Angular app that handles routing and it's at the root directory.
I've tried stuff like this:
AliasMatch ^/(.+) /var/www/html/mywebsite.com
But it always results in an infinite loop.
Essentially, I just want to disable path-directory resolution.
EDIT: I should also clarify that I have multiple sites hosted on the same machine and still want that to function. I just don't want directory routing from within a single website.
I figured out how to accomplish what I want while also having the neat side effect of allowing me to still have assets that can be reached through directory navigation:
FallbackResource /
Will use the root directory without changing the URL when no such directory the path specifies exists.
I have my .htaccess file, and I have a folder with config files in there, and they contain sensitive content, e.g. database details etc. What I would like to know is, how can I block access from a browser, but allow them to be accessed via my scripts?
I know that this can be achieved inside the PHP files themselves, but I'd rather use the .htaccess approach where possible.
Is this actually able to be done? I've attempted it before, but in the process of denying access to the file from the browser, it also denied access from the coding.
I have looked into this before, and some of the answers I came across suggested changing the extension to something like .inc, and then denying access to that. However, a couple of issues I have with that is that a) It instantly alerts anyone that can see that filename, for whatever reason, that it is a config file. Also, b) If my denial code breaks, browsers will not parse it as a PHP file, but rather an inc file, meaning it will print the code in the browser.
Basically, can this be done within a .htaccess file, or do I need to put something in the header of every config file?
Put these files outside of your web server's document root.
You can still access them via your server-side scripts, but this ensures no direct access to them from the outside world.
The conventional advice is to place such files "outside of your web server's document root". This is all well and good, but many shared hosting offerings only give write access to your public_html directory.
I use a simple convention: any private content (that is not URI addressable) is prefixed by an underscore or in a directory that's name is prefixed with an underscore (eg. _private or _include). I then include this rewrite rule in my DOCROOT .htaccess file:
# if a forbidden directory or file name (starting with a . or /)
# then raise 404 Fatal return
RewriteRule (^|/)[_.] - [F]
Remember that you'll need to prefix with a RewriteEngine On and/or include this at the top of any .htaccess file with the engine enabled.
Note that the "." prefix picks up files such as .htaccess.
Please use a framework, these kind of issues just doesn't need to exist. If you insist though, write a .htaccess to redirect every request to a single index.php in the root directory, which then have more logic to determine whether or not the request is for a valid file and include them, otherwise generate 404 or 403. If you need performance for static files, then use RewriteCond to exclude specific directories or file type from the index.php check.
IIS does URL cleanup on directories by adding a trailing slash. See this old docs from IIS 6:
IIS generates courtesy redirect when folder without trailing slash is requested
Why? Is the intent still relevant?
Any security implications?
How can I disable it to make this work with a URL Rewrite rule "RemoveTrailingSlashRule"
When you add a rule under IIS 7.5 with URL Rewrite 2, the rule will not be applied to directories (using IsDirectory) and folders (using IsFolder).
See this warning on Add a rule to append or remove the trailing slash symbol:
This will create the RemoveTrailingSlashRule1:
I have an answer for the specific case of a child IIS Application here: https://stackoverflow.com/a/25817317/292060. The child app seems to be the usual culprit, but isn't explicitly described in this question.
To try to answer the questions, here are my opinions from dealing with IIS and Microsoft for years. I don't have hard sources to cite; some of this is just gut feelings.
Why? Is the intent still relevant?
I think it stemmed from the original "default document" feature, namely index.html. Websites wanted their home page to just be the domain, then this extended to subfolders. With url rewriting, the intent isn't relevant anymore - you can rewrite to your heart's content, and would rather IIS get out of the way. It's common to want friendly urls, and no trailing slash (except for the domain/website root - that is required to have a trailing slash, even if some browsers like Chrome get cute and hide it).
Any security implications?
I think the only security implication was the original directory browsing. If you forgot to do a default document, and directory browsing was left turned on, then people could browse your website files. As far as I know, directory browsing has been long disabled as the default setting.
With any requests, whether trailing slash or not, url rewriting or not, your server and code need to withstand bad requests. This is true for all situations, not just specific to the slashes. http://xkcd.com/327/
How can I disable it to make this work with a URL Rewrite rule "RemoveTrailingSlashRule"
I have an answer if the issue is the child application, here: https://stackoverflow.com/a/25817317/292060
The summary is, in IIS:
Disable the Default Document feature for the child application.
Using Url Rewrite, create a rule to rewrite (not redirect) an empty request to default.aspx
If this question is for a more general issue, including regular subfolders even if not a child app, consider removing the "Is Not a Directory" from the rule, and let this redirect even when it sees a directory. That may work, or may create an infinite redirect loop, I'm not sure.
What are the different approaches to securing a directory?
including an index page so contents can't be viewed
the problem with this is that people can still access the files if they know the filename they're after
including an htaccess file to deny all
this seems to be the best approach, but is there any case that an htaccess file can be passed by? are there any cases as well where htaccess is not available?
restricting folder access
this is also a nice solution, but the problem is, the folder I'm trying to secure should be viewable and writable by the program.
Are there any other ways that folder security can be done?
Best practice for Apache is to use htaccess to restrict - this only restricts from the webserver - but that should be what you need. You can add authentication into this - but for most needs to you can just deny all acess - which hides the directory completely.
Another method that can also work well with using htaccess to deny direct access would be to use htaccess in your route directory to rewrite urls. This means that a request such as /example/listItems/username/ted can be rewritten as a call to a php or other file such as:
/application/index.php?module=listItems&username=ted
The advantage of doing this is that the webserver does not give out paths to any directories so it is much more difficult for people to hack around looking for directories.
If you want to protect a directory of images you could also use htaccess to redirect to a different directory so that /images/image5.png is actually a call to :
/application/images/image5.png
You could also try not placing your protected directory under your www dir but on other "non www visible" location. If your app needs to read / write data, tell it to do it on the other location. Modify its properties so only the app has the proper rights to do so.