Rails 7 connect to Twitter API strict-origin-when-cross-origin error - twitter-oauth

Context: attempting to connect to twitter API Oauth2 version, after submitting twice, both with and without the following block initializers/content_security_policy.rb
Rails.application.configure do
config.content_security_policy do |policy|
policy.default_src :self, :https
policy.font_src :self, :https, :data
policy.img_src :self, :https, :data
policy.object_src :none
policy.script_src :self, :https
policy.style_src :self, :https
# # Specify URI for violation reports
# # policy.report_uri "/csp-violation-report-endpoint"
end
end
via the following rendered rails code to HTML form
<%= form_tag('/auth/twitter2', method: 'post', data: {turbo: false}) do %>
<button type='submit'>Login with Twitter</button>
<% end %>
<form data-turbo="false" action="/auth/twitter2" accept-charset="UTF-8" method="post"><input type="hidden" name="authenticity_token" value="mU-GNjvKcWumrWZME_EszVTvi5wxo_5si89wOyCzCM0_SOmjAWQp1Vb8Gey71T1vCkRE9hahDd7r5zLpip1d_A" autocomplete="off">
<button type="submit">Login with Twitter</button>
</form>
The same was attempted with both a localhost:3000 host and an ngrok.io host
The console for the browser complains with the data at bottom.
Notes:
• the client ID is correct as set in the credentials
• the redirect_url has a slash removed from the string, yet it is present in the Twitter developer console https://https://170-343e-5-92-35.eu.ngrok.io/auth/twitter2/callback.eu.ngrok.io/auth/twitter2/callback
• twitter seems to recognize an active user x-twitter-active-user
It appears the API recognizes user but returns an error for lack of a security policy.
Yet something is wrong / missing here. What is it?
gems used are:
gem "omniauth", "~> 2.1"
gem "omniauth-rails_csrf_protection", "~> 1.0"
gem "omniauth-twitter2", "~> 0.1.0"
XHR GET https://twitter.com/i/api/2/oauth2/authorize?code_challenge=VqpkyR0-V1CTxnWXCdv0GCN_YP0fxX4JG0CggNxzDlo&code_challenge_method=S256&client_id=QkNaZGYxdXV2VVBteUhOZnZDZmQ6MTpjaQ&redirect_uri=https://170-343e-5-92-35.eu.ngrok.ioauth/twitter2/callback&response_type=code&scope=tweet.read users.read&state=274c1aa25c3274500095c77115cb4acc246fb9615e82f81a
[HTTP/2 400 Bad Request 187ms]
GET
scheme
https
host
twitter.com
filename
/i/api/2/oauth2/authorize
code_challenge
VqpkyR0-V1CTxnWXCdv0GCN_YP0fxX4JG0CggNxzDlo
code_challenge_method
S256
client_id
XV2VhQkNaZGYxdOZVBteUnZDZmQ6MTpjaQ
redirect_uri
https://170-343e-5-92-35.eu.ngrok.ioauth/twitter2/callback
response_type
code
scope
tweet.read users.read
state
274c1aa25c3274500095c77115cb4acc246fb9615e82f81a
Address
104.244.42.129:443
Status
400
Bad Request
Version HTTP/2
Transferred 706 B (132 B size)
Referrer Policy strict-origin-when-cross-origin
cache-control
no-cache, no-store, max-age=0
content-disposition
attachment; filename=json.json
content-encoding
gzip
content-length
128
content-type
application/json;charset=UTF-8
date
Mon, 31 Oct 2022 13:20:46 GMT
perf
7626143928
server
tsa_o
strict-transport-security
max-age=631138519
x-connection-hash
97ae1535e53b9ac87a0e6dc13996c3433bbbbaa470309893496090c60964af9d
x-content-type-options
nosniff
X-Firefox-Spdy
h2
x-frame-options
SAMEORIGIN
x-response-time
137
x-transaction-id
51c8c8c80424d52b
x-xss-protection
0
Accept
*/*
Accept-Encoding
gzip, deflate, br
Accept-Language
en-US,en;q=0.5
authorization
Bearer AAAAAAAAAAAAAAAAAAAAANRILgH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhAAAAAAnNwIzUejRCOuLTvJu4FA33AGWWjCpTnA
Connection
keep-alive
Cookie
guest_id=v1%3A165780214435378276; ct0=4020832aeed06194a4a62c8e5cc444311104716913ea7dcd10c30bb3dccfc87204d0ecf06771c5be6912634af55dd73edef992ae81eb79b1f507c8a79a50723aa018762a63ce9bca4aac58de0c35aedf; d_prefs=MjoxLGNvbnNlbnRfdmVyc2lvbjoyLHRleHRfdmVyc2lvbjoxMDAw; kdt=IZm9EbuU31Z5S5qEyVo0YPtSiIgF8djIWpHREbzq; twid=u%3D829665148143022080; auth_token=615b92f058b05ed8cd8829494d9421c5bb35a34a; night_mode=2; eu_cn=1; _twitter_sess=BAh7CyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCPgH%252FvyBAToMY3NyZl9p%250AZCIlYmQ2YjVhYWNkYTYyZTQyYjI1YjEzNzkwYWM0MThmNWE6B2lkIiUyMjg0%250AZWZkZDMzZjcwMGU2NjVmMjhmNDY4Yzc3ZGI4NjofbGFzdF9wYXNzd29yZF9j%250Ab25maXJtYXRpb24iFTE2NjcyMDY2MjM0ODkwMDA6HnBhc3N3b3JkX2NvbmZp%250Acm1hdGlvbl91aWQiFzgyOTY2NTE0ODE0MzAyMjA4MA%253D%253D--bf686a94467ee3b422f132c9b1b181de4480d7e6; des_opt_in=N
DNT
1
Host
twitter.com
Referer
https://twitter.com/i/oauth2/authorize?client_id=QkNaZGYxdXV2VVBteUhOZnZDZmQ6MTpjaQ&code_challenge=VqpkyR0-V1CTxnWXCdv0GCN_YP0fxX4JG0CggNxzDlo&code_challenge_method=S256&redirect_uri=https%3A%2F%2F170-343e-5-92-35.eu.ngrok.ioauth%2Ftwitter2%2Fcallback&response_type=code&scope=tweet.read+users.read&state=274c1aa25c3274500095c77115cb4acc246fb9615e82f81a
Sec-Fetch-Dest
empty
Sec-Fetch-Mode
cors
Sec-Fetch-Site
same-origin
TE
trailers
User-Agent
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:106.0) Gecko/20100101 Firefox/106.0
x-csrf-token
4020832aeed06194a4a62c8e5cc444311104716913ea7dcd10c30bb3dccfc87204d0ecf06771c5be6912634af55dd73edef992ae81eb79b1f507c8a79a50723aa018762a63ce9bca4aac58de0c35aedf
x-twitter-active-user
yes
x-twitter-auth-type
OAuth2Session
x-twitter-client-language
en

There was another gem involved: Devise
Although config/initializers/devise.rb did not include any references to
config.omniauth :twitter2 it still conflicted with the omniauth gem.
Removing omniauth was necessary, in addition to configuring the devise initializer, to properly connect with twitter provider (exactly twitter2 for OAuth 2.0 connections).

Related

Access-Control-Allow-Origin equals origin but the browser still denies access... why?

I have an application (React SPA) that calls a bunch of servers on different subdomains of the application domain, i.e.:
the web app sits at foo.bar.com,
and talks to api.foo.bar.com and media.foo.bar.com.
When accessing api.foo.bar.com, I get an error from the browser (be it Edge, Chrome, or Firefox) telling me that the origin (foo.bar.com) is different from the value of the Access-Control-Allow-Origin response header. However, by inspection of the response, they are the same:
(I unfortunately have to obfuscate the address.)
Those apps are hosted on Kubernetes; the ingress is NGINX, and it's is not providing CORS (cors-enabled annotation is false). Both applications (api and media) are Express apps, and both have the same CORS configuration allowing the specific origin.
I'm wondering if this has something to do with the redirect - the call to the media... endpoint returns a redirect (302) whose Location is a api... address.
Other than that, I have no clue what could be wrong. Something is, for sure, because all browsers agree that my request should be blocked (on account of the origin).
In all cases, I've checked the address multiple times for typos, ending forward-slashes, etc. I've called OPTIONS on those endpoints with cURL and Postman, using all headers or just a few. They always answer the correct address.
Additional information, as requested:
Preflight request:
OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: feedurl
Referer: https://aiXXXXXXXXXXXXXXXX.com/
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Preflight response:
HTTP/2 204 No Content
date: Fri, 08 Oct 2021 13:33:10 GMT
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXXXX.com
vary: Origin
access-control-allow-credentials: true
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-headers: Content-Type, feedUrl
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
Request
The preflight passes, and the browsers starts a "flight" request:
GET /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
feedUrl: https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Referer: https://aiXXXXXXXXXXXXXXXXX.com/
Cookie: ory_kratos_session=MTYzMzYzODY1OHxEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiXXXXXXXXXXXXYVc1bkRDSUFJSHBtUWxsaWFsVlJhWGRTVGxSMmIzZHRkbTFqYm5CUlRWVkdkelpPWkRoWnXXXTyqwgK-0Pe0qtZHjNhfU-YoASjg3istMZi672swQ==
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Response
HTTP/2 302 Found
date: Fri, 08 Oct 2021 13:33:10 GMT
content-type: text/plain; charset=utf-8
content-length: 129
location: https://api.aiXXXXXXXXXXXXXXXXXX.com/media/1.0.0/hls/streams/19dd149d-f551-4093-b2aa-e5558388d545/hls.m3u8
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXX.com
vary: Origin, Accept
access-control-allow-credentials: true
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
At this response, the browser fails saying that the origin don't match the access-control-allow-origin.
(the first image was from Edge, since the log was more clear; this log is from Firefox)
Problem
The error message—I'm using dummy URLs and origins below—from the browser can be a bit confusing:
Access to XMLHttpRequest at 'https://api.example.com/' (redirected from 'https://media.example.com/') from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://example.com' that is not equal to the supplied origin.
The key here is that, as sideshowbarker hinted at in his comment, because your first preflighted request to https://media.example.com/ responds with a cross-origin redirect to https://api.example.com/, the browser performs another whole CORS access-control check for that resource. However, because the redirect resulting from the first preflighted request happens to be cross-origin, the browser sets the origin of the second preflight request (which the error message refers to as the "supplied origin"), not as https://example.com, but as the null origin!
Here's a rundown of what is likely happening:
Because https://api.example.com likely doesn't (and shouldn't!) allow the null, the second access-control check fails and you get that annoying CORS error.
Solution
Resist the temptation to allow the null origin on https://api.example.com/, as doing so has serious security ramifications: it amount to voiding the protection that the Same-Origin Policy provides.
Instead, you should get rid of that redirect from https://media.example.com/ to https://api.example.com/ and make your frontend request the https://api.example.com/ resource directly.
Alternatively, if you cannot completely get rid of the redirect but you can change its destination, make it a same-origin redirect (from somewhere https://media.example.org to elsewhere on https://media.example.org).

sapui5 OData.V4.oDataModel with Teiid 11.2 / Wildfly

I am trying to use SAPUI5 in a SPA to display data from a TEIID/Wildfly ODataV4 service. When SAPUI5 ODATA V4 data model is bound to the service, I run into several errors. I thereby connect via proxy (grunt-connect-proxy2) to the odata service. Basic Auth works. The metadata file above the marked service folder in the attached image (screenshot1) is the actual metadata file of the service which, as you can see, is loaded correctly. So no CORS issue or authorization issue.
Screenshot1
The issue seems to be related to an CSRF Token request as far as I understand. Seems that Teiid/Wildfly is not answering the CSRF Token fetch request. Is there a way to configure Wildfly to answer the request or alternatively a way to disable CSRF requests for the odata V4 model? I have seen such an option in the constructor of the odata V2 model. How could a working configuration look like?
The following is a screenshot from the browser log:
I observed a further issue, from which I do not know if it is related to the previous one (there is also a X-CSRF-Token: Fetch involved), or if a have something more missing somewhere. The second issue happens when I use an aggregation binding to bind a odata collection to a sapui5 list. The response looks like
Request URL: http://localhost:9001/odata4/svc/my_nutri_diary/$batch
Request Method: POST Status Code: 406 Not Acceptable Remote Address:
[::1]:9001 Referrer Policy: no-referrer-when-downgrade Response
Headersview source access-control-allow-credentials: true
access-control-allow-origin: http://localhost:9001 cache-control:
no-cache, no-store, must-revalidate connection: close
content-encoding: gzip content-length: 125 content-type:
application/json;odata.metadata=minimal date: Mon, 12 Nov 2018
20:04:30 GMT expires: 0 odata-version: 4.0 pragma: no-cache server:
WildFly/11 x-powered-by: Undertow/1 Request Headersview source Accept:
multipart/mixed Accept-Encoding: gzip, deflate, br Accept-Language: de
Authorization: Basic SU1TVXNlcjpJTVM0Zm9ydW0l Connection: keep-alive
Content-Length: 329 Content-Type: multipart/mixed;
boundary=batch_id-1542053070786-11 Cookie: sidebar_collapsed=false;
cycle_analytics_help_dismissed=1;
__utmz=111872281.1539128843.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=111872281.767670437.1539128843.1541866362.1541870562.42 DNT: 1 Host: localhost:9001 MIME-Version: 1.0 OData-MaxVersion: 4.0
OData-Version: 4.0 Origin: http://localhost:9001 Referer:
http://localhost:9001/ User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS
11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko)
Version/11.0 Mobile/15A372 Safari/604.1 X-CSRF-Token: Fetch
X-Requested-With: XMLHttpRequest Request Payload
--batch_id-1542053070786-11 Content-Type:application/http Content-Transfer-Encoding:binary GET Profile?$skip=0&$top=100 HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
--batch_id-1542053070786-11--
Thanks for your advice!
Best regards,
Christoph
Further note regarding search for a workaround: As I am currently searching for a workaround to be able to use the odata.v4 model, I found the following blog post:
https://blogs.sap.com/2015/08/05/disable-csrf-token-for-odata-calls-using-sap-netweaver-gateway/
However, the approach does not seem to work for the odata.v4 model as it has a different interface. There is no setHeaders() function to set custom headers on the datamodel. I therefore tried to set the header up via
$.ajaxSetup({headers: {'X-Requested-With': 'X'}});
Unfortunately, this also does not work. If someone has the odata.v4 Model running with TEIID or Olingo v4 it would be great if he could give me a feedback on how he had worked around this issue.

Uber API issue with CORS

First time asking a question here. I'm a beginner at this, but i'm truly stumped at the problem i'm facing.
Browsers in use:
Safari and Firefox (both on Mac OS Sierra)
Firefox (Linux - Ubuntu 16.04.2)
I am registered as an Uber Developer and have registered an App in the Dashboard. I'm only using the Server Token for authentication at the moment. In the Dashboard, I have set the following entries in the "Authorizations" tab of the App for CORS (Optional URI for CORS Support):
http://localhost:8000 <-- web server in my PC
https://subdomain.mydomain.com <--- remote web server
A few months ago i created a web app using HTML, CSS and JS (with Jquery v2.2.4) to play around with the Ride Estimates API and was able to get it to report data for many locations in my area successfully. Somehow it no longer works. I'm trying to fix that and improve the functionality. However, i just can't get past the initial query to the API because of CORS issues that were not existent before.
My API URL is:
https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}
When i paste that in the address bar of the browser i get valid JSON:
{"prices":[{"localized_display_name":"uberX","distance":1.58,"display_name":"uberX","product_id":"811c3224-5554-4d29-98ae-c4366882011f","high_estimate":3,"surge_multiplier":1.0,"minimum":2,"low_estimate":2,"duration":420,"estimate":"2-3\u00a0$","currency_code":"USD"},{"localized_display_name":"X English","distance":1.58,"display_name":"X English","product_id":"8fe2c122-a4f0-43cc-97e0-ca5ef8b57fbc","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"uberXL","distance":1.58,"display_name":"uberXL","product_id":"eb454d82-dcef-4d56-97ca-04cb11844ff2","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber Black","distance":1.58,"display_name":"Uber Black","product_id":"ba49000c-3b04-4f54-8d50-f7ae0e20e867","high_estimate":6,"surge_multiplier":1.0,"minimum":4,"low_estimate":4,"duration":420,"estimate":"4-6\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber SUV","distance":1.58,"display_name":"Uber SUV","product_id":"65aaf0c2-655a-437d-bf72-5d935cf95ec9","high_estimate":7,"surge_multiplier":1.0,"minimum":5,"low_estimate":5,"duration":420,"estimate":"5-7\u00a0$","currency_code":"USD"}]}
I then proceed to set up JS (w/ JQuery) code in webpage...
var url = "https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}";
$.getJSON(url, function(result){
console.log(result);
});
Uploading the HTML and JS to my remote web server and then loading the webpage in any of my browsers yields a 200 status from Uber API. However, the console log shows CORS blocking my request (PROBLEM #1):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Then, in the Inspector view of both Mac Browsers, under the Network / Resources areas, i see the 200 Status message from the GET request. However, along with the Response message (PROBLEM #2):
SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
The Request Headers are:
GET /v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********} HTTP/1.1
Host: api.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://subdomain.domain.com/Uber/index.html
Origin: https://subdomain.domain.com
Connection: keep-alive
The Response Headers are:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 19 Mar 2017 22:26:31 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Content-Geo-System: wgs-84
Content-Language: en
X-Rate-Limit-Limit: 2000
X-Rate-Limit-Remaining: 1998
X-Rate-Limit-Reset: 1489964400
X-Uber-App: uberex-nonsandbox, optimus, migrator-uberex-optimus
Strict-Transport-Security: max-age=604800
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
In Firefox for Linux i sometimes don't get the Syntax Error; i always seem to get it on the Mac Browsers. In Linux, when i do get that error, then clicking on the "Edit and Resend" Headers button (resending the Headers but without really editing the Headers), the Syntax Error disappears and the Response text actually shows the Uber API Object that is supposed to be there... but i still get the CORS Blocked message on the Console Log. I really don't understand why this is, but it seems contradictory. In the end, i am unable to get to use the API data that, using the same method months ago, i could get for several dozens of locations.
I have looked for answers in similar questions but so far have found none that apply to my case. Any help will be greatly appreciated. Getting really frustrated... really stuck here.
This issue was caused by the API not including the header correctly. This issue is resolved and the api is now working as expected. Also, the allow origin header will only be returned in a response if an origin is specified in the request.

IE11 - LOSING MY COOKIES: 302 redirect from HTTP to HTTPS

Using IE11 I am making a get request to SITE A:
GET http://www.test.com/?documentId=ef746317-7711-4458-8873-a73700fc1b85 HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
Connection: Keep-Alive
Host: www.test.com
I receive a redirect with 2 cookies:
HTTP/1.1 302 Found
Date: Wed, 15 Mar 2017 23:48:00 GMT
Content-Type: text/html; charset=UTF-8
Location: https://www.newSite.com/test/Edit/ef746317-7711-4458-8873-a73700fc1b85
Set-Cookie: Auth=EAAAAIQfMoK32BNjBypXapcJppWc==; path=/; secure
Set-Cookie: Auth=EAAAAN+xPT6eioV8LESTR6CViGIvc834gP==; path=/; secure
Cache-Control: private, s-maxage=0
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 4.0
X-Powered-By: ASP.NET
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"
P3P: policyref="/w3c/p3p.xml", CP="IDC DSP COR IVAi IVDi OUR TST"
Content-Length: 0
IE would appear to be following the redirect and does a GET, but as you can see is not sending back the cookies:
GET https://www.newSite.com/test/Edit/ef746317-7711-4458-8873-a73700fc1b85 HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
Connection: Keep-Alive
Host: www.newSite.com
And then of course is the 401:
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Wed, 15 Mar 2017 23:48:00 GMT
Content-Length: 1293
<HTML>Blah blah blah access denied error</HTML>
I tried adding the P3P headers to force IE to send the cookies in the redirect but no dice. I have read there may be an issue with IE sending cookies in redirect when going from HTTP to HTTPS, or because the "secure" cookies are being sent back to the browser on HTTP which when redirects to HTTP sees the different domain and chokes. I cannot change the web sites as they are vendors, but I can alter the 302 being sent back to IE11 with the interface middle-ware I am working on. Any thoughts on how I can trick/force IE to send back these cookies on the redirect?
Update 1: I have tried Firefox 52, IE11, and Chrome. No browser is accepting that 302 and sending the get back with the cookies. Someone out there must understand how redirects with cookies work. No responses makes me wonder if this site is reaching the right people.
I got around my issue with sort of a hack. Since the browser would not forward cookies back in a 302 redirect, I just send back a little page that does the posting for me, instead of my interface software.
<!DOCTYPE html>
<html>
<head>
<title>Redirect</title>
</head>
<body>
<form action="https://testAPI.test.com/" method="POST">
<input name="UserName" value="Test APIUser"/>
<input name="UserEmail" value="test#test.com"/>
<input name="PatientId" value="1d11eb2e-2606-485e-ad5d-a70c00daa37a"/>
<input name="Timestamp" value="Mon, 20 Mar 2017 19:11:24 GMT"/>
84c6-a7210111648b"/>
<input name="Token" value="MRVp/pBRBJ08F8cYMavfL8 ="/>
</form>
<script language="javascript"> window.setTimeout('document.forms[0].submit()', 0);</script>
</body>
</html>
You can disable Protected Mode. Protected Mode is designed to prevent malicious software from exploiting vulnerabilities in Internet Explorer 11. This mode may also block cookies depending on the current setup.
Open Internet Explorer 11.
Click Tools and then select Internet options.
Go to Security tab.
Under Security level for this zone, clear the check box for Enable Protected Mode (requires restarting Internet Explorer).
Click OK.
Close Internet Explorer 11 and then launch it again.

Application Permissions Request Endlessly Redirects with IE

This code works great for all browsers except Internet Explorer.
Basically when the redirect is sent to IE it just request the exact same URL again from my server, it just ignores the redirect.
Using the 3.1.1 code from Naitik Shah
Here's the code:
// $g_facebook is declared earlier and given app id and secret
$par[ 'scope' ] = array( 'publish_stream' , // publish to the user's stream
'offline_access' , // access these functions when the user is offline
// 'user_status' , // get the user's latest status
// 'read_stream' , // read the user's stream
'email' , // provides the user's email address
'user_groups' , // provides the user's groups
// 'sms' , // send and receive txt w/ user
'publish_actions', // publish scores and achievements
);
header( 'Location: ' . $g_facebook->getLoginUrl( $par ) );
exit( );
Here's what happens on the wire (picked it up with tcpdump):
GET /fork HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
Accept-Encoding: gzip, deflate
Host: fbar.toolsteam.com
Connection: Keep-Alive
Cookie: PHPSESSID=7f32d7e4acd63696bd8d0998913f608c; PHPSESSID=e30076106b21e40142397219283fd55f
HTTP/1.0 302 Moved Temporarily
Date: Mon, 07 May 2012 07:36:12 GMT
Server: Apache
X-Powered-By: PHP/5.3.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=a9f17a1119dc262bef693d2d39a15317; expires=Tue, 07-May-2013 07:36:12 GMT; path=/
Location: http://www.facebook.com/dialog/oauth?client_id=336243633108439&redirect_uri=http%3A%2F%2Ffbar.toolsteam.com%2Ffork&state=b52dd5dd08e0058e28ae8734f269cd77&scope=publish_stream%2Coffline_access%2Cemail%2Cuser_groups%2Cpublish_actions
Content-Length: 0
Content-Type: text/html
X-Cache: MISS from base
X-Cache-Lookup: MISS from base:3128
Via: 1.1 base:3128 (squid/2.7.STABLE9)
Connection: keep-alive
When IE sees the 302 it just sends the original request again and again. It never follows the redirect to facebook.
As said before, Chrome and Firefox have no problems.
Ideas?
The answer was in the request headers:
Cookie: PHPSESSID=7f32d7e4acd63696bd8d0998913f608c; PHPSESSID=e30076106b21e40142397219283fd55f
There are two servers involved in this facebook auth, one is the originating website, the second is an intermediate server that negotiates the facebook permissions. The facebook server is a sub-domain of the primary site.
Turns out both of them were starting php sessions. The facebook server's cookie was at the sub-domain scope, the primary site's cookie was at the top-domain scope.
For whatever reason IE couldn't handle sending the same cookie twice on a request to the facebook server - it handled the transaction just fine but for whatever reason would just re-request the same URL and ignore the 302 redirect. IE is like that.
I switched the session variable name on the facebook server and the problem disappeared.