Is it possible to store the Authorization header or feed the header as part of an environment? I keep various server URLs in my environment but the Auth header needs to change as part of that as well...
It's definitively possible. Here's a doc article about it:
https://luckymarmot.com/paw/doc/Environments_as_Reusable_Presets
Related
Is there a way to tell the browser not to share a cached resource among websites?
I want to give websites a link to some JavaScript on my server and I want to make the response be different for each domain using the Referer header as check.
The response which will be cached should be available to the domain that requested it and when the end users visit another site that uses the script link, another request should be made.
I don't know whether I understand your question.
Does your scenario like: stackoverflow.com and yourwebsite.com use the same script called "https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js", but you don't want to share the cached script with stackoverflow.com
This is under the control of googleapis.com's web server.
So if the cached resource's origin server(googleapis.com) want to implement the feature as you said, it may use the Vary response header. Vary Header define the secondary key of cache.
Maybe "Vary: Origin" but only work for CORS
Maybe "Vary: referer" but referer contains url path
It still doesn't solve your problem but I hope it helps.
see MDN HTTP Cache Doc and [RFC 7234 Section 4.1]
I develop software which stores files in directories with random names to prevent unauthorized users to download a file.
The first thing we need about this is to store them in a separate top-level domain (to prevent cookie theft).
The second danger is HTTP referer which may reveal the name of the secret directory.
My experiments with Chrome browser shows that HTTP referer is sent only when I click a link in my (secret) file. So the trouble is limited only to files which may contain links (in Chrome HTML and PDF). Can I rely on this behavior (not sending the referer is the next page is opened not from a current (secret) page link but with some other method such as entering the URL directly) for all browsers?
So the problem was limited only to HTML and PDF files. But it is not a complete security solution.
I suspect that we can fully solve this problem by adding Content-Disposition: attachment when serving all our secret files. Will it prevent the HTTP referer?
Also note that I am going to use HTTPS for a man-in-the-middle not to be able to download our secret files.
You can use the Referrer-Policy header to try to control referer behaviour. Please take note that this requires clients to implement this.
Instead of trying to conceal the file location, may I suggest you implement proper authentication and authorization handling?
I agree that Referrer-Policy is your best first step, but as DaSourcerer notes, it is not universally implemented on browsers you may support.
A fully server-side solution is as follows:
User connects to .../<secret>
Server generates a one-time token and redirects to .../<token>
Server provides document and invalidate token
Now the referer will point to .../<token>, which is no longer valid. This has usability trade-offs, however:
Reloading the page will not work (though you may be able to address this with a cookie or session)
Users cannot share URL from URL bar, since it's technically invalid (in some cases that could be a minor benefit)
You may be able to get the same basic benefits without the usability trade-offs by doing the same thing with an IFRAME rather than redirecting. I'm not certain how IFRAME influences Referer.
This entire solution is basically just Referer masking done proactively. If you can rewrite the links in the document, then you could instead use Referer masking on the way out. (i.e. rewrite all the links so that they point to https://yoursite.com/redirect/....) Since you mention PDF, I'm assuming that this would be challenging (or that you otherwise do not want to rewrite the document).
What is the use of X-Mx-ReqToken HTTP header? Almost all tutorials on enabling CORS in nginx whitelist the X-Mx-ReqToken header. But I can't find any information on the purpose of the header.
X-Mx-ReqToken is a header used to supply a profiler key for Mendix Runtime:
Member Data Documentation
final String com.mendix.systemwideinterfaces.core.IProfiler.PROFILER_KEY = "X-Mx-ReqToken" [static]
Basically, this is just a case of copying & pasting the same snippet over and over again until it made it to every nginx CORS tutorial out there. But unless you actually use said profiler, it's safe to omit.
For example,I hava a pnacl myapp.pexe , And my website is www.A.com. and myapp.pexe and www.A.com are on the same server. However, the website www.B.com need to access the myapp.pexe. And i got a error, Native Client: access to manifest url was denied.
Using CORS can slove this problem? If using CORS can slove this problem, how to do ?
This answer is not Native Client specific. Accessing Native Client resources from another origin uses the standard CORS mechanism.
To answer your question, though:
This can be done by setting up the correct CORS response headers on the A.com server. There are many online resources that can describe how to do this: take a look at http://www.html5rocks.com/en/tutorials/cors/ for example.
For the simplest case, the solution is to return one additional header in the GET response for myapp.pexe and myapp.nmf:
Access-Control-Allow-Origin: http://A.com
There are more headers that are required for other request method types, content types, sending credentials, etc.
Lets say you want to serve different content from the same url but still want to be able to use squid caching.
For example caching a logged in users homepage vs another user. Is there anyway to append a cookie to the request url before throwing it into the squid's cache?
Use the vary header .
So you can have multiple version of a page depending of the vary header. But the browser must send the variant header so you don't have a lot of choice to do this. Cookie header can be use if your use case. Be careful PURGE method doesn't work with variant cache in squid !
Try playing with storeurl_rewrite_program:
http://www.squid-cache.org/Versions/v2/2.7/cfgman/storeurl_rewrite_program.html
Basically, it acts like a normal Squid rewrite / redirector program, but it ONLY affects the URL used to look up / store in the cache.