As explained in https://web.dev/samesite-cookies-explained/, Chrome will enable SameSite=lax by default if SameSite is not specified.
In Apex, we can set Cookie using Cookie ck = new Cookie('cookieLabel','cookieValue',null,-1,false);
How can I set SameSite=None;Secure for ck variable of Cookie class?
As far as I can tell, the Apex Cookie Class does not support the SameSite attribute at all.
As a result, I would investigate using HttpResponse.setHeader() directly:
httpResponse.setHeader('Set-Cookie', 'cookieLabel=cookieValue; SameSite=None; Secure');
Be aware though, in other frameworks I do see the cookie handling overwrite any existing Set-Cookie headers so you may want to ensure you do any manual setting of headers either before or after the in-built cookie handling.
I would also raise a feature request for full support of the SameSite attribute in the framework.
Related
My requirement is to enable "secure" flag in one of the header called "_adminv2_session" but which contains a dynamic value. I was trying to enable the flag using the below configurations in nginx, but it'll create a new header with same name and assign value "/"
add_header Set-Cookie "_adminv2_session=/; HttpOnly; Secure";
But when I try without value, it gives errors,
add_header Set-Cookie "_adminv2_session; HttpOnly; Secure";
Can anyone help me on enable secure flag on the so called header in nginx ?
Screenshot of current status,
Thanks.
You might need to use proxy_cookie_path and add_header directives like this.
As far as I understood, you need to set your _adminv2_session variable value first, then to add Secure flag to your Set-Cookie header.
Also you can use directive more_set_headers from 3rd-party headers_more module to do you task in one directive.
more_set_headers 'Set-Cookie: $sent_http_set_cookie; HttpOnly; Secure';
I have searched a lot and still couldn't find a solution, I am using nodejs with express which is setting etag to true by default, I tried all of the solutions i found online and it is still set, examples:
res.set('etag', false);
res.removeHeader('ETag');
app.disable('etag');
app.use(express.static(__dirname + '/public'), { etag: false });
And still it is set, so, is there something i am missing here since i am not really that experienced in node or express.
My question is obviously, how to disable this header, because, I have a page with a lot of images (A LOT) and all of them are static and etag is causing a lot of blocking since it's sending requests to check validity and preventing the browser from relying on cache-control, which is hugely increasing page load time.
Thanks for the help
Refer to: http://expressjs.com/4x/api.html#app.set
You can do it in ExpressJS 4 using:
app.set('etag', false);
Setting it to false disables the etag header altogether while the default is set to true.
Possible option values are:
Boolean (true,false)
String ('strong', 'weak')
Function
This is not a full answer but I am adding it just in case anyone faces the same issue.
It turned out what I was missing is that the browser forces a cache validity check on first load (including page refresh), and that's why I kept seeing the etag header.
To properly test if the header is removed you have to browse to the url and check not go directly to it.
I hope this helps someone, because it took me a while to find it out
IOwinContext does not appear to have the HTTP Referrer in it, and I need to grab it. What is the right way to get that particular variable? IOwinContext has several Typed PEMs but I don't see referer in particular.
The system I am working is self-hosted.
Thanks.
The OwinContext doesn't have 'HTTP Referer' as item in Request header. This has been renamed in Owin self host context. It's now known as 'Referer'. So once you have object of owin context you can get the information by using:
context.Request.Headers["Referer"]
I can not for the life of me find any documentation regarding the possible properties of varnish (version 3) objects.
We know (from googling, varnish documentation just mumbles and leaves you more frustrated) for example that the request object has the url property (req.url) and also that it has req.http.X-Forwarded-For. But has anyone ever in any way found... say... a list?
Thanks!
/joakim
You can't really give a comprehensive list of things like req.http.X-Forwarded-For because req.http.* are HTTP headers. The Cookie header of a request will be req.http.Cookie and the User-Agent header will be req.http.User-Agent. There are a lot of standard headers, but you can set any arbitrary header and it will show up in req.http.___________. You can see the headers of the HTTP response in resp.http.*. Same for backend response in beresp.http.*.
All of the other properties are listed here: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#variables
I'm trying to get CORS working on my trigger.io app:
I've got the following setup in my .htaccess
Header set Access-Control-Allow-Headers: "Accept,Origin,Content-Type,X-Requested-With"
Header set Access-Control-Allow-Methods "GET,PUT,POST,DELETE,OPTIONS"
Header set Access-Control-Allow-Credentials: "true"
Header set Access-Control-Allow-Origin "http://localhost:3000,content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"
Running the trigger App in the web (localhost:3000) works fine.
But when I deploy it to an (android) device I see the following error in the debug output:
[ERROR] XMLHttpRequest cannot load {link}http://mydevtest.lan/api/auth/currentuser.{/link} Origin content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c is not allowed by Access-Control-Allow-Origin. -- From line 1 of null
I'm fearing that setting content:// in the Access-Control-Allow-Origin header is not legal.
The Access-Control-Allow-Origin header as you have it is invalid. Valid values are either '*', or a space separated list of origins. One of the following should work:
Header set Access-Control-Allow-Origin "*"
or
Header set Access-Control-Allow-Origin "http://localhost:3000 content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"
Note that I've never tested the latter form (with multiple origins). While the CORS spec allows it, browsers may not yet support it.
One other thing you could do is read in the value of the Origin header, validate it on your server (i.e. manually check that the value equals either "http://localhost:3000" or "content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"), and then echo only that value in the Access-Control-Allow-Origin response header. However this requires a little more work since it introduces some server-side conditional processing.
I also fear that content:// is not allowed in CORS, could you try setting Access-Control-Allow_origin to *, if that works then that is probably the problem.
A better solution would be to avoid doing XHR requests and use forge.request.ajax which will make the request from native code and avoid any cross domain restrictions. You can find the documentation for that here http://docs.trigger.io/en/v1.4/modules/request.html#modules-request