I know it is a big topic in the internet, but I could not find any working solution till now.
Some of my clients integrate my website thourgh a iframe. In Firefox/Chromium everything works fine after I set the SameSite attribute to None and added Secure to it.
Now there is also a IE11 in the world and I don't know what to do else to make it my cookies right, so the IE11 accepts them.
This is what the IE11 gets:
Set-Cookie: JSESSIONID=CFA2E0643F0CA81B68B4A984D7FC429D; Path=/; Secure; HttpOnly;SameSite=None;Secure
Set-Cookie: JSESSIONID=CFA2E0643F0CA81B68B4A984D7FC429D; Expires=Mon, 05-Oct-2020 15:19:46 GMT; Path=/; Secure; HttpOnly;SameSite=None;Secure
Set-Cookie: my-cart=f5e5dcea-8d9e-33a6-b228-9e7e6dc04f4a; Expires=Wed, 03-Mar-2032 06:19:46 GMT; Path=/; Secure; HttpOnly;SameSite=None;Secure
Set-Cookie: sessionExpiry=; Max-Age=3605; Expires=Mon, 05-Oct-2020 15:19:51 GMT; Path=/; Secure;SameSite=None;Secure
Set-Cookie: anonymous-consents=%5B%5D; Max-Age=31536000; Expires=Tue, 05-Oct-2021 14:19:46 GMT; Path=/;SameSite=None;Secure
Set-Cookie: cookie-notification=NOT_ACCEPTED; Max-Age=360000000; Expires=Wed, 03-Mar-2032 06:19:46 GMT; Path=/; Secure;SameSite=None;Secure
As you can see, the Path starts with /. The Expires is set, if needed and the time is correct.
Is there anything else what I missed?
As you're using Windows Server 2012, the root cause of the issue is that SameSite cookie is only supported in IE 11 on Windows 10 RS3 (2017 Fall Creators Update) and newer. So it doesn't work on your machine.
More information to reference:
(1) caniuse website
(2) SameSite Browser Compatibility
(3) Change status of SameSite cookie
To make cross domain cookies work with IE, I found some similar threads: link1, link2, and they all point to using P3P policy. You can refer to this answer for the detailed information about how to use P3P policy.
Related
I have an IdentityServer4 implementation that has a default internal OIDC OpenIdConnect middleware to provide access to local APIs and support for external login providers, starting with Microsoft. I've implemented a custom IClientStore and attach it to the middleware with
.AddClientStore<IS4ClientStore>();
When the internal OIDC implicit connection auths, IS4ClientStore.FindClientByIdAsync is called by BuildLoginViewModelAsync like the example with
_clientStore.FindEnabledClientByIdAsync(context.ClientId);
which returns the expected IdentityServer4.Client and everything authenticates, etc.
When I call the external provider (Microsoft OAuth), it goes through the auth process connecting to my supplied applicationid, goes through the claims process by Microsoft and then Microsoft redirects back to https://localhost:5001/signin-microsoft.
The asp.net core middleware from calling services.AddAuthentication().AddMicrosoftAccount(options) in startup isn't using my client store to look up the client id, it just reports the error:
Request starting HTTP/1.1 GET https://localhost:5001/signin-microsoft?code=M91ae2ef1-701d-ceb4-d479-a905d3d02a4d&state=CfDJ8GGNLFmYOI9KouhmbB3NzeJ5omhARPg-YVCPW7u1aCyhnGfOx9_Nj4VL8cMIxmO48nk_8UkfB9Pv7Q7tzZZb8nsq5y26giY9fXuVyRsn5qx8a1nSX8tKFWk1uo9ongL5V0MXY6sgU6eNUEzsxgyNFz_20QLVU20y9G7jRpmxoOcpQ1s1SJx0Tu2BBlRrI840-D-jUmg1ix7xDUfmXF_rPVp6e88rzIuCfbQO4otNq2fAsm4
info: Microsoft.AspNetCore.Authentication.MicrosoftAccount.MicrosoftAccountHandler[4]
Error from RemoteAuthentication: OAuth token endpoint failure: Status: BadRequest;Headers: Cache-Control: no-cache, no-store
Pragma: no-cache
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: 759b3046-cbad-489d-98c1-6e83bb390b00
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: fpc=AZFdz4kBW-ZHi5twlc6DCrARHQUSAQDQZKAdWIfWCA; expires=Sat, 02-Mar-2019 08:43:04 GMT; path=/; secure; HttpOnly, x-ms-gateway-slice=prod; path=/; secure; HttpOnly, stsservicecookie=ests; path=/; secure; HttpOnly
Date: Thu, 31 Jan 2019 08:43:04 GMT
;Body: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier '000000005D256100' was not found in the directory '9188040d-6c67-4c5b-b112-36a304b66dad'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant\r\nTrace ID: 759b3046-cbad-489d-98c1-6e83bb390b00\r\nCorrelation ID: 858c340d-7c0c-4fa9-86c2-f8417e5915f1\r\nTimestamp: 2019-01-31 08:43:04Z","error_codes":[700016],"timestamp":"2019-01-31 08:43:04Z","trace_id":"759b3046-cbad-489d-98c1-6e83bb390b00","correlation_id":"858c340d-7c0c-4fa9-86c2-f8417e5915f1"};.
fail: Microsoft.AspNetCore.Server.Kestrel[13]
Connection id "0HLK7ARJEPT98", Request id "0HLK7DAJEPT98:00000005": An unhandled exception was thrown by the application.
System.Exception: An error was encountered while handling the remote login. ---> System.Exception: OAuth token endpoint failure: Status: BadRequest;Headers: Cache-Control: no-cache, no-store
Pragma: no-cache
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: 759b3046-cbad-489d-98c1-6e83bb390b00
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: fpc=AZFdz4kBW-ZHi5twlc6DCrARHQUSAQDQZKAdWIfWCA; expires=Sat, 02-Mar-2019 08:43:04 GMT; path=/; secure; HttpOnly, x-ms-gateway-slice=prod; path=/; secure; HttpOnly, stsservicecookie=ests; path=/; secure; HttpOnly
Date: Thu, 31 Jan 2019 08:43:04 GMT
;Body: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier '000000005D256100' was not found in the directory '9188040d-6c67-4c5b-b112-36a304b66dad'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant\r\nTrace ID: 759b3046-cbad-489d-98c1-6e83bb390b00\r\nCorrelation ID: 858c340d-7c0c-4fa9-86c2-f8417e5915f1\r\nTimestamp: 2019-01-31 08:43:04Z","error_codes":[700016],"timestamp":"2019-01-31 08:43:04Z","trace_id":"759b3046-cbad-489d-98c1-6e83bb390b00","correlation_id":"858c340d-7c0c-4fa9-86c2-f8417e5915f1"};
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
at IdentityServer4.Hosting.FederatedSignOut.AuthenticationRequestHandlerWrapper.HandleRequestAsync() in C:\local\identity\server4\IdentityServer4\src\Hosting\FederatedSignOut\AuthenticationRequestHandlerWrapper.cs:line 38
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at IdentityServer4.Hosting.BaseUrlMiddleware.Invoke(HttpContext context) in C:\local\identity\server4\IdentityServer4\src\Hosting\BaseUrlMiddleware.cs:line 36
at Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Request finished in 476.3734ms 500
Am I supposed to use an implementation of AddMicrosoftAccount from IdentityServer4?
Thanks to Jim & Mackie to point me in the right direction (I thought it was due to a custom store implementation issue on my side)
When I was verifying I had the right clientid and secret on the https://apps.dev.microsoft.com/#/appList page, I noticed a link to go to the azure portal to manage my apps. (https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/applicationsListBlade) When I went to that link, the previous apps I had didn't show, so I just created a new app and got a new ApplicationId (which was now a guid instead of in through the portal) and Secret, plugged that into the .AddMicrosoftAccount call and I was able to go through the Auth process through microsoft login and get a token to finish the auth on my server.
My guess is that some percentage of applications that were added through the apps.dev.microsoft.com site aren't in Microsoft's backing store when finishing the auth process, the applications may be in the front-end query and allow the auth pages to find your application and provide the consent page, but then when issuing the token, the Microsoft side is looking in a different store and not finding the application by the ApplicationId provided through the apps.dev.microsoft.com page. So the solution, at least in my case, was to create the application in the azure portal instead.
Cloudflare suddenly returns a 302 redirect to the origin domain, which breaks our AJAX calls, although the CORS headers are still in place.
curl -I https://cloudflare-domain.com/channel/4d90dd64aa4a4fd8a3cad8862fd88c67/?limit=12
HTTP/1.1 302 Found
Date: Fri, 29 Sep 2017 15:38:22 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Set-Cookie: __cfduid=dc5840cbd96478011d1bb040fcb6fc7e81506699502; expires=Sat, 29-Sep-18 15:38:22 GMT; path=/; domain=.cloudflare-domain.com; HttpOnly
Location: https://origin-domain.com/channel/4d90dd64aa4a4fd8a3cad8862fd88c67/?limit=12
CF-Cache-Status: HIT
Expires: Fri, 29 Sep 2017 17:38:22 GMT
Cache-Control: public, max-age=7200
Server: cloudflare-nginx
CF-RAY: 3a600770fec427aa-FRA
We haven't changed any settings, either in Cloudflare or on the origin server.
Any ideas why this could suddenly happen?
Found the problem: a change was made on the origin server.
We put in a redirect to enforce HTTPS, but Cloudflare was connecting over HTTP. The redirect was being returned by the origin server.
Solution: In the Cloudflare settings, under Crypto, select Full SSL (strict).
Update: Go to search and type "SSL/TLS"
and change to Full strict
Screenshot SSL/TLS Settings 302 Found cloudflare
I've been using the Office 365 Calendar REST api for a few weeks with several users.
I'm currently experiencing something very wierd:
When fetching events of a specific user with the /calendarview call (via OAUTH2). I get perfect results (though very slow), EXCEPT when 25/01 is between my start_date and end_date, I get :
{"error":{"code":"ErrorInternalServerError","message":"Object
reference not set to an instance of an object."}}"
I suspect one the event of this user is causing this, but still, the API should not bug ?
Any clue?
Here are the instrumented logs:
GET /api/v1.0/me/calendars/AQMkAGVmMjlhY2E5LWE4MmMtNGFhAGMtYjY5OC0wNmRiMWYxZDJkM2UARgAAA4ZtZygzpnpGt-RyQ8uQQ80HAG6teJW1hzZBuLm47wZiBYIAAAIBBgAAAG6teJW1hzZBuLm47wZiBYIAAAIM4gAAAA==/calendarview?&startDateTime=2015-02-24T23:55:38Z&endDateTime=2015-02-25T23:55:38Z&$top=50&$skip=0
HTTP/1.1
Content-Type: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: */*
User-Agent: Ruby, JulieDesk
Authorization: Bearer $REFRESHTOKEN$
Return-Client-Request-Id: true
Client-Request-Id: be203946-93b7-47f6-b402-edbd0ed49653
Host: outlook.office365.com
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Server: Microsoft-IIS/8.0
request-id: 4a0fe2ba-a761-4526-bd09-70c81e084cb5
client-request-id: be203946-93b7-47f6-b402-edbd0ed49653
Set-Cookie: ClientId=LSM5BXAUPUIJBVFLY0LDA; expires=Tue, 16-Feb-2016 23:55:39 GMT; path=/; secure; HttpOnly
X-CalculatedBETarget: co1pr07mb316.namprd07.prod.outlook.com
OData-Version: 4.0
X-DiagInfo: CO1PR07MB316
X-BEServer: CO1PR07MB316
X-AspNet-Version: 4.0.30319
Set-Cookie: exchangecookie=7b08adfab00641009c1cbbf90594797d; expires=Tue, 16-Feb-2016 23:55:40 GMT; path=/; HttpOnly
Set-Cookie: X-BackEndCookie2=3bd486f8-787b-435b-8269-5359cdbcc7ce=u56Lnp2ejJqBxsmZysiemc/SyMmazNLLyJvO0sbGxs3Smc+bm87Pz8+dm8aegYHNz87K0s/M0s7Hq83MxcrKxcvJgZGeko+Nm8/I0Y+NkJvRkIqLk5CQlNGckJI=; expires=Wed, 18-Mar-2015 23:55:46 GMT; path=/api; secure; HttpOnly
Set-Cookie: X-BackEndCookie=3bd486f8-787b-435b-8269-5359cdbcc7ce=u56Lnp2ejJqBxsmZysiemc/SyMmazNLLyJvO0sbGxs3Smc+bm87Pz8+dm8aegYHNz87K0s/M0s7Hq83MxcrKxcvJ; expires=Wed, 18-Mar-2015 23:55:46 GMT; path=/api; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: DM2PR09CA0014
Date: Mon, 16 Feb 2015 23:55:45 GMT
Content-Length: 111
-> "{\"error\":{\"code\":\"ErrorInternalServerError\",\"message\":\"Object reference not set to an instance of an object.\"}}"
Sorry about the odd error! I'd definitely like to find out more. Could you add client instrumentation to your request, reproduce the error, and let me know the values of the HTTP response headers in that article?
I had this issue when filtering by Subject where some events didn't have a subject.
I fixed this by including Subject ne null in the filter query
I'm trying to use the Office 365 api to fetch user's calendar events. I managed to get a valid oauth2 access_token, but when I use the api, the authentication fails.
GET https://outlook.office365.com/api/v1.0/me/calendars
Headers:
Authorization: Bearer **MYACCESSTOKEN**
A very slow response (about 5 secs) give me a 401 Unauthorized...I have already checked that my access_token is not expired.
Response headers:
Cache-Control: private
Content-Length: 0
Date: Thu, 06 Nov 2014 10:53:12 GMT
Request-Id: d2a72db7-0e72-4ef4-8579-97453a28656b
Server: Microsoft-IIS/8.0
Set-Cookie: ClientId=BWUSNGYUIVTW9QOSG; expires=Fri, 06-Nov-2015 10:53:08 GMT; path=/; HttpOnly, exchangecookie=723dca46630646a2bc80b4668dd113d7; expires=Fri, 06-Nov-2015 10:53:13 GMT; path=/; HttpOnly, X-BackEndCookie2=5a7ff0a2-22c1-4d5b-b280-6af6689779a7=u56Lnp2ejJqBxpqdxs3IzczSmpzHzdLLnc7P0p7Gx5nSyMrGm5ydzMyencbKgZKejZOWmo3RkJGSlpyNkIyQmYvRnJCSgc3PzsvSzs3Sz8mrzs/FyszFzsyBmoqNj42bz87Rj42Qm9Gah5yXnpGYmpOenYzRnJCS; expires=Sat, 06-Dec-2014 10:53:13 GMT; path=/api; secure; HttpOnly, X-BackEndCookie=5a7ff0a2-22c1-4d5b-b280-6af6689779a7=u56Lnp2ejJqBxpqdxs3IzczSmpzHzdLLnc7P0p7Gx5nSyMrGm5ydzMyencbKgZKejZOWmo3RkJGSlpyNkIyQmYvRnJCSgc3PzsvSzs3Sz8mrzs/FyszFzsw=; expires=Sat, 06-Dec-2014 10:53:13 GMT; path=/api; secure; HttpOnly
Www-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000#*", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token",Basic Realm="",Basic Realm=""
X-Aspnet-Version: 4.0.30319
X-Beserver: AMSPR01MB103
X-Calculatedbetarget: amspr01mb103.eurprd01.prod.exchangelabs.com
X-Diaginfo: AMSPR01MB103
X-Feserver: BLUPR07CA059
X-Ms-Diagnostics: 2000001;reason="The audience claim value is invalid '00000002-0000-0000-c000-000000000000'.";error_category="invalid_token"
X-Powered-By: ASP.NET
Any idea ?
Thanks for your question. The 30s delay with some requests is a known issue and we are already working on a fix to address this. Sorry for the inconvenience.
Thanks,
Venkat
Ok I finally managed to get a 200. My problem was the resource param when asking a token was set by defaut to 00000002-0000-0000-c000-000000000000 (I'm using Rails omniauth-azure-oauth2 gem).
I changed it to https://outlook.office365.com and it works.
Still, the api give me the right answers, but the call is ultra-slow (up to 30s !). Any clue on how to make it respond in a reasonable time ?
I'm trying to give my webshop a boost with warnish.
Setup varnish port 80, backend is 127.0.0.1 apache2.
Apache Benchmark gives awefull resulst, like 1-2 request/sec !
On the very first displayed file; header.tpl I have :
<?php
cache_control( "public, s-max-age=6000");
expires( to_gmt( time() + 6000 ) );
?>
Below is the response header:
HTTP/1.1 200 OK
Content-Length: 151613
Expires: Tue, 26 Feb 2013 20:04:07
Cache-Control: public, s-max-age=6000
Pragma: no-cache
Set-Cookie: PHPSESSID=i9h5ldj8k4fking69d03jr5244; path=/, language=en; expires=Thu, 28-Mar-2013 18:24:06 GMT; path=/; domain=www.domain.com, currency=CHF; expires=Thu, 28-Mar-2013 18:24:06 GMT; path=/; domain=www.domain.com
Content-Type: text/html; charset=utf-8
Accept-Ranges: bytes
Date: Tue, 26 Feb 2013 18:24:07 GMT
X-Varnish: 186646239
Age: 0
Via: 1.1 varnish
Connection: close
X-Cache: MISS
Must be missing something obvious but to me varnish just doesn't cache; what am i doing wrong ?
PHP most likely has session.cache-limiter set to nocache (the default).
This would send a Pragma: no-cache (and as far as I understand an Expire header set to the current time) to Varnish and thus disabling caching.
Varnish will ignore the « Pragma : no-cache » by default, unless it is instruction to handle the directive (https://varnish-cache.org/docs/4.0/users-guide/increasing-your-hitrate.html).
Your cache-control seems to be configuring properly and should be cached for 6000 second.
The next things that you need to take into consideration are the cookie. Looking in your header, you have a PHP session Cookie:
Set-Cookie: PHPSESSID=i9h5ldj8k4fking69d03jr5244;
Varnish will not cache the cookie unless you remove it the request in your vcl file. Ex :
sub vcl_recv {
set req.http.Cookie = regsuball(req.http.Cookie, "PHPSESSID =[^;]+(; )?", "");
}