Is there any way to cache request with auth headers in varnish - varnish

Is there any way to cache request with auth headers in varnish?
I want to ignore the auth headers while caching the request

There are various ways to approach this, depending on the importance of auth headers.
1. You don't care about auth
If you don't care about the auth part and if you want to risk serving cached content to unauthorized users, you can just use the following VCL code:
sub vcl_recv {
unset req.http.Authorization;
}
2. Ignore authorization to some extent
It is also possible to care about auth a bit, but not too much.
The following VCL snippet will allow caching even if there is an Authorization header:
sub vcl_recv {
if(req.http.Authorization) {
return(hash);
}
}
The consequence of this is that the initial cache miss will pass through to the backend and will be processed there. Potential unauthorized access will be handled there.
But as soon as the has been dealt with, the object is stored in the cache and the next requests will get cached content regardless of the authorization status of that request.
3. Perform auth on the edge
It is also possible to handle the auth part in Varnish while caching the content.
The following VCL code will handle this:
sub vcl_recv {
if(req.http.Authorization != "Basic YWRtaW46c2VjcmV0") {
return (synth(401, "Restricted"));
}
unset req.http.Authorization;
}
sub vcl_synth {
if (resp.status == 401) {
set resp.http.WWW-Authenticate = {"Basic realm="Restricted area""};
}
}
This code will actively inspect the content of the Authorization header and will ensure the username admin is used with password secret.
The YWRtaW46c2VjcmV0 string is nothing more than a base64 encoding of admin:secret.
4. Use vmod_basicauth
A more advanced and flexible way to terminate auth on the edge is by using https://git.gnu.org.ua/vmod-basicauth.git/. This VMOD can be compiled from source and can be downloaded from ftp://download.gnu.org.ua/release/vmod-basicauth.
Assuming the credentials are stored in /var/www/.htpasswd, you can leverage this VMOD to match the Authorization header to the content of the .htpasswd file.
Here's the VCL:
vcl 4.1;
import basicauth;
sub vcl_recv {
if (!basicauth.match("/var/www/.htpasswd",req.http.Authorization)) {
return (synth(401, "Restricted"));
}
unset req.http.Authorization;
}
sub vcl_synth {
if (resp.status == 401) {
set resp.http.WWW-Authenticate = {"Basic realm="Restricted area""};
}
}

This is entirely possible but also extremely dangerous: Varnish would return the same cached (authorized) content to all requests.
Example:
User A requests resource Z with proper authentication. Varnish relays the request to backend, caches the response and returns the resource.
User B requests resource Z with proper authentication. They will get the cached resource Z even if Z contains user A's content.
User X requests resource Z with invalid authentication. They will too get the cached resource anyway since the backend is bypassed.
Having said that, you can override Varnish's built-in VCL. Details are documented but the main idea is:
Copy default vcl_recv VCL (for your version) from source and add it to the end of your vcl_recv.
Remove the safeguards from vcl_recv: Just remove vcl_req_authorization which disables caching:
sub vcl_req_authorization {
if (req.http.Authorization) {
# Not cacheable by default.
return (pass);
}
}
In your vcl file issue a return statement at the end so built-in vcl is not used.

Related

Varnish how to cache for mobile and desktop site

I want to know how to cache for mobile and desktop site. I have mobile and desktop site whose root is written in nginx. Mobile/Desktop is served to the user based on the user-agent whenever the user visits the site, so in this scenario how to cache for mobile and cache for desktop site so that when the user visits the website, Get the right content from the cache.
Please help to write VCL for mobile and desktop cache in Varnish.
You can download https://github.com/varnishcache/varnish-devicedetect/blob/master/devicedetect.vcl and include this file in your main VCL file. By calling the devicedetect subroutine in your main VCL file.
This subroutine will set a X-UA-Device header that contains the device type, which you can then vary on.
Here's an example:
vcl 4.1;
backend default {
.port = "8080";
}
include "devicedetect.vcl";
sub vcl_recv {
call devicedetect;
if(req.http.X-UA-Device ~ "^(mobile|tablet)\-.+$") {
set req.http.X-UA-Device = "mobile";
} else {
set req.http.X-UA-Device = "desktop";
}
}
sub vcl_hash {
hash_data(req.http.X-UA-Device);
}

Remove s-maxage from Cache-Control header using Varnish

We're currently using the s-maxage directive in the Cache-Control header from our origin to control the TTL in Varnish. However, I'd like to remove it from the response before delivery, so that no other caches in the request chain act on it.
I'm currently looking at the header VMOD, to remove s-maxage from the header, but leave the rest of it intact. I believe this could be achieved with something like this:
sub vcl_deliver {
header.regsub(resp, "s-maxage=[0-9]+,?\s?", "")
}
As a newcomer to Varnish, I wanted to sanity-check this approach and make sure there isn't a better way to tackle it?
Appreciate any support or advice.
Replace header at delivery time
The following VCL snippet will strip off the s-maxage attribute from the Cache-Control header before it is sent to the client.
sub vcl_deliver {
set resp.http.cache-control = regsub(resp.http.cache-control,
"(,\s*s-maxage=[0-9]+\s*$)|(\s*s-maxage=[0-9]+\s*,)","");
}
Replace header at storage time
It is also possible to strip off this attribute from the Cache-Control header before it gets stored into a cache object. In that case, you'll use the beresp.http.cache-control variable inside vcl_backend_response.
sub vcl_backend_response {
set beresp.http.cache-control = regsub(beresp.http.cache-control,
"(,\s*s-maxage=[0-9]+\s*$)|(\s*s-maxage=[0-9]+\s*,)","");
}
Using vmod_headerplus
If you're using Varnish Enterprise, you can use the vmod_headerplus module to easily delete header attributes:
vcl 4.1;
import headerplus;
sub vcl_deliver {
headerplus.init(resp);
headerplus.attr_delete("Cache-Control","s-maxage",",");
headerplus.write();
}
vcl 4.1;
import headerplus;
sub vcl_backend_response {
headerplus.init(beresp);
headerplus.attr_delete("Cache-Control","s-maxage",",");
headerplus.write();
}
Although Varnish Enterprise is the commercial version of Varnish Cache, you can still use it without upfront license payments if you use it on AWS, Azure or GCP.
Varnish Enterprise on AWS
Varnish Enterprise on Azure
Varnish Enterprise on GCP

Azures Arr Affinity response cookie

Once you consume and set Azure ARRAffinity response cookie and send it back to Azure, are you supposed to get it back with next response ?
I just completed bit of code what brings Azure response cookie all the way to browser, sets it as a session cookie and then I pass it back to Azure in request as a cookie. To my surprise I am not getting this cookie back, I see it only the first time. However I have a feeling this might be expected behaviour - I could find anything in the documentation. When I try to change the cookie to some made up value, the correct cookie is returned with the next response.
public class RestRequestWithAffinity : RestRequest
{
public RestRequestWithAffinity(string resource, IRequestWithAffinity request)
: base(resource)
{
if (!string.IsNullOrEmpty(request.AffinityValue))
{
AddCookie("ARRAffinity", request.AffinityValue);
}
}
}
var request = new RestRequestWithAffinity(url, feedRequest)
{
Method = Method.GET
};
// cookie doesn't come back when already in request
IRestResponse response = await _client.ExecuteTaskAsync(request);
Yes, you supposed to get it back with next response. You can take a look on the following link:
http://azure.microsoft.com/blog/2013/11/18/disabling-arrs-instance-affinity-in-windows-azure-web-sites/
if you create the cookie, than choose a different name and everything will be fine! ARRAffinity is a reserved name by the IIS ARR Module. And that's why you may see this misbehavior.
Also pay attention that if you use the public Microsoft provided domains (i.e. yourdomain.cloudapp.net or yourdomain.azurewebsites.net) you cannot set the cookie at top domain level - i.e. you cannot set cookie for the cloudapp.net domain or for the azurewebsites.net domain. You shall always use the full domain, including any subdomains to set the cookie - i.e. yourdomain.azurewebsites.net.
Take a read here for more information about that issue: https://publicsuffix.org/learn/

Set Varnish headers conditionally based on client.ip

How would I use client.ip as a conditional in setting headers in the fetch section of a Varnish 3.0 VCL? I have some troubleshooting headers that I like to set to solve caching issues, however, I don't want them publicly visible. I'd love to be able to whitelist the headers for my ip address only.
Is there any way to access client.ip in _fetch?
You can best set all troubleshooting headers in you _recv without any conditions and remove them in you vcl deliver. this way you dont need to add the same ip check on every conditional header
if you want to use an ip range you can use the following code
acl debug {
"your ip adress1";
"you ip adress 2";
}
in you vcl_recv
if (!client.ip ~ debug) {
set req.http.x-debug = "debug";
}
in you vcl_deliver
if(!req.htt.x-debug){
remove resp.http.debugheader1;
remove resp.http.debugheader2;
}

Servicestack - Call AuthProvider automatically

I would like to build my own AuthProvider. It should
Check if ss-id cookie is set and check for a valid session (this is
done automatically in servicestack)
If no valid session was found check a custom http-header (e.g. X-Api-Token)
If found a valid token create a new session
If not found a valid token send 401 Unauthorized
Basically this is the behaviour of the CredentialsAuthProvider except that I need to check for the X-Api-Token without making an explicit call to /auth/credentials. However the AuthProvider is never called automatically.
Any ideas how to get this done?
Edit: One idea was to use a request filter but there is still something missing:
this.GlobalRequestFilters.Add((request, response, arg3) =>
{
//If there is a valid ss-id cookie the it should have precedence and the request should be authenticated accordingly
if (!ValidatedViaSsIdCookie())
{
if (HeaderHasCorrectApiKey()) {
//Authenticate the current request by creating a new Session
AuthenticateRequest();
}
}
}
);
How to implement ValidatedViaSsIdCookie() and AuthenticateRequest()???
Edit: I don't think GlobalRequestFilters are the way to go because they will be executed after authentication... So if there is no valid session the filter is not executed at all and my Api key is never checked... Still searching for a better solution...
Regards
Dirk

Resources