Sending a 403 status with every request using htaccess - .htaccess

In addition to noindex and other headers, I want to send 403 status with every request on a dev server we use. I have put an .htaccess file in the home dir (above the web root) so that every request is tagged, and all seems to be working well, minus the 200 OK status.
Is there a way that .htaccess can set status as 403 to all requests without actually triggering the forbidden page mechanisms? This would work similar to how php can do it with header('HTTP/1.1 403 Forbidden');. I don't wanna have to worry about putting header() style fixes all over the stuff below in the folders....would be far easier and more consistant via .htaccess (with ability to tag assets to boot).

Related

.htaccess, displaying 404 page without changing the user-entered url (no redirection)

So, my problem goes like this:
I created a custom 404 error page (error.html) and I want it to be displayed without actual redirection to the page, thus, keeping the user-entered URL. Examples:
User puts "http ://localhost/whatever.the.url/would/be" in their address bar.
error.html displays, but the URL in the address bar remains as entered by user: "http
://localhost/whatever.the.url/would/be"
I tried other people's guides and answers but they didn't work for me, perhaps because I'm really amateur and I have no idea how .htaccess actually works, sorry.
In addition to that, my .htaccess currently looks like this:
ErrorDocument 404 http://localhost/www.minimalistik.de/fejle/404/fejl.html/
Yeah it isn't much. Thanks to everyone who'd help me with this :)
To serve the error document via an internal subrequest (ie. the URL in the browser's address bar does not change) then simply specify a root-relative URL (starting with a slash) to your error document in the ErrorDocument directive (this is generally considered "normal" behaviour).
For example, if your error.html file is in the /error-documents subdirectory off the document root then you would use the following:
ErrorDocument 404 /error-documents/error.html
The user is not externally redirected to the error document.
ErrorDocument 404 http://localhost/www.minimalistik.de/fejle/404/fejl.html/
However, when you specify an absolute URL (ie. with scheme + hostname) as in this example then Apache triggers a 302 (temporary) redirect to the error document and the user is externally redirected. No "404 Not Found" response is returned to the client, unless the error document itself is returning a 404 status. And if it's returning a 200 OK (the default) then the error document itself could potentially be indexed by search engines! Needless to say, this is not recommended and is an error in most scenarios.
Reference:
https://httpd.apache.org/docs/2.4/mod/core.html#errordocument

How to intercept or pause http status code 301 request in a browser

I am looking for a solution to interrupt or pause a 301 ( redirect ) request in Chrome dev tools. My scenario is I have an API integration with a local payment gateway which requires 301 redirect to their server ( HTTP GET and then redirect with 301 to an external URL). As 301 HTTP status code happens on the client-side so this can be compromised as the current system does not protect the integrity of the data, for instance, the amount to pay. I might send 100$ and the user might change it to 20$.
To prove this I need to stop the request manually which is very inconvenient and hard to test. I am looking for a solution that implements in one of my favorite browsers above that allows me to config to interrupt or pause the 301 HTTP status code so I can easily modify the value in the URL before resuming the request.
I found a chrome extension to solve this issue.
Requestly is easy to use and test. This is what being mentioned in the extension page:
Chrome Extension to modify HTTP requests (Setup Redirects, Run Custom
Javascript, Modify Headers
But my scenario is about modifying url query string - not being mentioned in the description but it works perfectly.

How to interpret HTTP Status Code 302 in an IIS web log

I am looking at my IIS web log and notice some log records with an sc-status of 302.
I did research and am only more confused.
At first, it looks simple, if a little vague.
"This is an example of industry practice contradicting the standard.
[...] Therefore, HTTP/1.1 added status codes 303 and 307 to
distinguish between the two behaviours.[25] However, some Web
applications and frameworks use the 302 status code as if it were the
303."
While I understand the concept, I am not sure which meaning to apply when viewing an IIS web log. Do I treat the 302 status code as a 303 ("See Other" -- a way to redirect to a new URL) or as a 307 ("Temporary Redirect")?
307 causes a redirect using the same "verb" that the original url was requested with. That allows POST data to be preserved. By contrast, 301/302 will always cause a GET of the new url, losing any POST data that may have been present.
As well, with 301/302, the browser can cache the response and always go to the new url, bypassing the original url. 307 requires that the original URL be hit again, even if it does end up being another redirect.

how to trash a cached http 302 response

I had an old website that permanently redirected (HTTP 302) all traffic from http://example.com/ to http://exmpale.com/drupal
now I re-implemented the entire website on wordpress but the old redirection is still cached on my user's browsers and breaking my revisiting users' experience (for some assets only).
I was thinking of adding to my new website a route serving as /drupal that will force the browser to trash the cache, is there a way to do so? maybe some http headers/javascript to trash the cache?
what do you think?
(BTW, I'm on a hosted service so my options are limited to php / .htaccess / javascript but I can't change http server configurations)
You said :
permanently redirected (HTTP 302)
But it's either:
temporary redirect (HTTP 302)
permanent redirect (HTTP 301)
302 responses are usually not cached in browsers. If you were using 301 response code this could be stored until the user close the browser. If you have problems with your users it certainly means you were using 301, but if it is not the case it means something between you and the final user is storing a cache of the redirection (like a reverse proxy cache in front of your server?).
If you were using a 301 you might try to add a temporary redirect on /drupal to /. But this may create an inifinite redirection loop on the browsers. You can maybe prevent it by adding a fake argument on the redirection, like redirectiong to /?redir=fix.

HTAccess Open only to Website

To secure my site I placed blank htmls along with an htaccess file in every subdirectory but I didn't realize the denying all access would also mean denying access from the website itself. When I try to load a page, and it goes into the Images folder, the server responds with:
Failed to load resource: the server responded with a status of 403 (Forbidden)
So how do I change this htaccess code:
order allow,deny
deny from all
Options All -Indexes
To deny access to everything outside of the website, meaning the website itself can access its own content (images, js, css) but no one outside can.
You've already accomplished your stated goal, but obviously that's not really what you're after. Basically everybody that browses to your site is coming from outside and requesting assets from your server. When I request index.html, or any other page from your server, it doesn't send me a complete package as it were, with all of the page's assets wrapped up inside, it just sends me the text that comprises index.html. At that point the browser parses that and handles it accordingy; when it comes across an image tag that has a src on your server, it fires off a new request for that asset, and hopefully your server sends it back in response. [Yes, I realize that was all ridiculously simplified.]
As you've got things set up now, you're denying access to anybody and everybody that requests any assets from your server, which is why you're getting the 403 responses. So whatever it is you actually want to do is going to require a more tightly focused approach. I'll take a stab at it and guess that what you really want to do is prevent people from hot-linking your images?

Resources