What is fetch's redirect and authorization headers expected behavior? (Safari has different behavior from other Mac browsers) - redirect

In short, when using an authorization header with the fetch api and a redirect is followed Chrome, FireFox, and Opera (on a Mac) include the authorization header in the second request. However, Safari (12.0.1) does not. From the fetch api spec and issue #553 my understanding is that the header should be included. Is this a correct understanding of how fetch is supposed to work?
Here's the simplified code I'm using with a workaround for Safari but I'd like to know if there's something I'm doing wrong that's causing the behavior with Safari or if there is a better workaround.
export async function loadData(token) {
const opts = {headers: {Authorization: `Bearer ${token}`}, credentials: 'include', redirect: 'follow'};
let response = await fetch('/api/data', opts);
// Work around for Safari not including headers in redirected request
if (response.status === 401 && response.redirected) {
response = await fetch(response.url, opts);
}
if (response.ok) {
return response.json();
}
return null;
}
Quick edit some additional info about the redirect. The redirected location is to the same origin and is a 302:
content-length: 118
content-type: text/plain; charset=utf-8
date: Mon, 26 Nov 2018 20:12:18 GMT
location: /api/data/current-version
server: nginx
status: 302
strict-transport-security: max-age=15768000
vary: Accept

Related

REST API call is unauthorized

I am trying to make a REST API call from my .Net MAUI mobile app.
First I log in, and get a JwtSecurityToken:
JwtSecurityToken JwtToken = new JwtSecurityToken(authenticationResult.IdToken);
Then I try to use it to make a REST API call:
HttpClient client = new ();
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", JwtToken.RawData);
HttpResponseMessage response = await client.GetAsync(url).ConfigureAwait(false);
response.EnsureSuccessStatusCode();
This gives me an exception
Response status code does not indicate success: 401 (Unauthorized).
What is wrong or missing here?
ADDED:
Here is the respose:
{StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
client-request-id: 162ea393-a9b2-4e6b-9786-d6e18d18afb1
Date: Sun, 25 Dec 2022 20:42:26 GMT
request-id: 162ea393-a9b2-4e6b-9786-d6e18d18afb1
Strict-Transport-Security: max-age=31536000
Transfer-Encoding: chunked
Vary: Accept-Encoding
WWW-Authenticate: Bearer realm="", authorization_uri="https://login.microsoftonline.com/common/oauth2/authorize", client_id="00000003-0000-0000-c000-000000000000"
X-Android-Received-Millis: 1672000947348
X-Android-Response-Source: NETWORK 401
X-Android-Selected-Protocol: http/1.1
X-Android-Sent-Millis: 1672000947271
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"E","Ring":"3","ScaleUnit":"005","RoleInstance":"CH01EPF000051D6"}}
Content-Type: application/json
}, Trailing Headers:
{
}}
If you are developing your own API, you can then set this flag to true:
.AddJwtBearer(options =>
{
options.IncludeErrorDetails = true;
...
Then you will see a reason in the response why it failed:
HTTP/1.1 401 Unauthorized
Date: Sun, 02 Aug 2020 11:19:06 GMT
WWW-Authenticate: Bearer error="invalid_token", error_description="The signature is invalid"

API Gate away Is Blocked even when CORS is enabled

I'm trying to make an api to upload images to cloudinary like this
fd.append('photos', file);
fd.append('upload_preset',
CLOUDINARY_UPLOAD_PRESET);
axios({
url: CLOUDINARY_API,
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
"Access-Control-Allow-Origin": "*",
'Access-Control-Allow-Headers': 'Origin',
'Access-Control-Allow-Credentials': true
},
data: fd
}).then(function(res) {
console.log(res);
}).catch(function(err) {
console.error(err);
})
})
but i recieve this error from the browser
Access to XMLHttpRequest at 'https://api.cloudinary.com/v1_1/******/mh/upload' from origin 'http://127.0.0.1:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.Blockquote
You will need to remove the three "Access-Control-Allow-*" headers from the request you are sending.
The headers Cloudinary allows for cross-origin requests don't include those headers which you are sending and therefore the browser throws this error.
Below are the headers that are allowed for cross-origin uploads (under Access-Control-Allow-Headers):
curl -sD - -X OPTIONS https://api.cloudinary.com/v1_1/demo/image/upload
HTTP/1.1 200 OK
Access-Control-Allow-Headers: Cache-Control, Content-Disposition, Content-MD5, Content-Range, Content-Type, DPR, Viewport-Width, X-CSRF-Token, X-Prototype-Version, X-Requested-With, X-Unique-Upload-Id
Access-Control-Allow-Methods: PUT, POST, GET, OPTIONS
Access-Control-Max-Age: 1728000
Cache-Control: no-cache
Content-Type: text/plain; charset=utf-8
Date: Sat, 19 Dec 2020 09:49:48 GMT
Server: cloudinary
Status: 200 OK
Vary: Accept-Encoding
X-Request-Id: d1af2a2f8a986d9ebbd1f14399dd409d
X-UA-Compatible: IE=Edge,chrome=1
X-XSS-Protection: 1; mode=block
Content-Length: 0
Connection: keep-alive
EDIT: In addition, Cloudinary API doesn't have a parameter called "photos". The file to upload is sent in the "file" parameter.
Therefore, you would need to replace fd.append('photos', file); with fd.append('file', file);.

Next.js dynamic api pages fail to respond to post requests with Content-Type=application/json headers

I've got a next.js react app running on a custom Express server with custom routes. I'm working on this project by myself, but I'm hoping I might have a collaborator at some point, and so my main goal is really just to clean things up and make everything more legible.
As such, I've been trying move as much of the Express routing logic as possible to the built in Next.js api routes. I'm also trying to replace all the fetch calls I have with axios requests, since they look less verbose.
// current code
const data = await fetch("/api/endpoint", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ foo: "bar" })
}).then(x => x.json());
// what I'd like
const data = await axios.post( "/api/endpoint", { foo: "bar" });
The problem I've been having is that the dynamic next.js api routes stall as soon as there's JSON data in the body. I'm not even getting an error, the request just gets stuck as "pending" and the await promise never resolved.
I get responses from these calls, but I can't pass in the data I need:
// obviously no data passed
const data = await axios.post( "/api/endpoint");
// req.body = {"{ foo: 'bar' }":""}, which is weird
const data = await axios.post( "/api/endpoint", JSON.stringify({ foo: "bar" }));
// req.body = "{ foo: 'bar' }" if headers omitted from fetch, so I could just JSON.parse here, but I'm trying to get away from fetch and possible parse errors
const data = await fetch("/api/endpoint", {
method: "POST",
// headers: { "Content-Type": "application/json" },
body: JSON.stringify({ foo: "bar" })
}).then(x => x.json());
If I try to call axios.post("api/auth/token", {token: "foo"}), the request just gets stuck as pending and is never resolved.
The Chrome Network panel gives me the following info for the stalled request:
General
Request URL: http://localhost:3000/api/auth/token
Referrer Policy: no-referrer-when-downgrade
Request Headers
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es;q=0.8
Connection: keep-alive
Content-Length: 26
Content-Type: application/json;charset=UTF-8
Cookie: token=xxxxxxxxxxxxxxxxxxxx; session=xxxxxxxxxxxxxxxxxxxxxxx
Host: localhost:3000
Origin: http://localhost:3000
Referer: http://localhost:3000/dumbtest
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36
Request Payload
{token: "foo"}
I've tried looking into what might be causing this, and everything seems to point towards there being an issue with preflight requests, but, since those are related to CORS policies, I don't understand why I'd be encountering those. I'm making a request from http://localhost:3000 to http://localhost:3000/api/auth/token.
Even so, I did try to add cors middleware as shown in the next.js example, but that didn't make a difference. As far as I can tell, the request never even hits the server - I've got a console.log call as the first line in the handler, but it's never triggered by these requests.
Is there something obvious I'm missing? This feels like it should be a simple switch to make, but I've spent the last day and a half trying to figure this out, but I keep reaching the same point with every solution I try - staring at a gray pending request in my Network tab and a console reporting no errors or anything.
After a few more hours searching, I found my answer here
Turns out that since I was using a bodyParser middleware in my express server, I had to disable the Next body parsing by adding this at the top of my file:
export const config = {
api: {
bodyParser: false,
},
}

Http request fail on NativeScript Angular

I have the Groceries tutorial, working. Then I go to the user service and change the URL of the login:
login(user: User) {
let headers = new Headers();
headers.append("Content-Type", "application/json");
return this.http.post(
"http://ws.u-vox.com/api/noauth/loginvenue",
JSON.stringify({
username: user.email,
password: user.password,
}),
{ headers: headers }
)
.map(response => response.json())
.do(data => {
Config.token = data.Result.access_token;
})
.catch(this.handleErrors);
}
handleErrors(error: Response) {
console.log(JSON.stringify(error.json()));
return Observable.throw(error);
}
When I press sign in I would expect a http message and a JSON on the terminal.
But instead I'm getting this mess, and I don't know what is happening.
CONSOLE LOG file:///app/shared/user/user.service.js:38:20: {"line":993,"column":38,"sourceURL":"file:///app/tns_modules/nativescript-angular/zone-js/dist/zone-nativescript.js","originalStack":"ZoneAwareError#file:///app/tns_modules/nativescript-angular/zone-js/dist/zone-nativescript.js:993:38\nfile:///app/tns_modules/tns-core-modules/http/http-request/http-request.js:86:37\nUIApplicationMain#[native code]\nstart#file:///app/tns_modules/tns-core-modules/application/application.js:211:26\nbootstrapApp#file:///app/tns_modules/nativescript-angular/platform-common.js:72:28\nbootstrapModule#file:///app/tns_modules/nativescript-angular/platform-common.js:60:26\nanonymous#file:///app/main.js:7:57\nevaluate#[native code]\nmoduleEvaluation#[native code]\n[native code]\npromiseReactionJob#[native code]","zoneAwareStack":"file:///app/tns_modules/tns-core-modules/http/http-request/http-request.js:86:37 [<root>]\nUIApplicationMain#[native code] [<root>]\nstart#file:///app/tns_modules/tns-core-modules/application/applicati
CONSOLE ERROR file:///app/tns_modules/nativescript-angular/zone-js/dist/zone-nativescript.js:569:26: Unhandled Promise rejection: Animation cancelled. ; Zone: <root> ; Task: null ; Value: Error: Animation cancelled. _rejectAnimationFinishedPromise#file:///app/tns_modules/tns-core-modules/ui/animation/animation-common.js:98:31 [<root>]
My endpoint works outside NativeScript app:
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Content-Type: application/json
Transfer-Encoding: chunked
Connection: close
Cache-Control: no-cache, private
Date: Thu, 28 Dec 2017 15:00:39 GMT
Allow: POST
{"username ... }
I think this issue is due to CORS (cross domain) request.
First make sure the url on which you make the post request have its CORS enabled.
Second, if you are using iOS to run your app, add the following to /nativescript/App_Resources/iOS/info.plist:
<key>NSAppTransportSecurity</key>
<dict>
<!--Include to allow all connections (DANGER)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
For android I think there is an equivalent setting.

How can I prevent Ext JS from including an entity body in DELETE requests using a restful store?

When Ext JS issues a DELETE request from a restful store, it includes an entity body. Although this doesn't seem to be forbidden by the HTTP spec, Google App Engine doesn't accept such requests. So I'd like to know if there is a way to prevent a restful store from including a redundant entity body on DELETE requests.
Details:
Using this sample as reference:
http://www.sencha.com/deploy/dev/examples/restful/restful.html
This is how the store is defined:
var store = new Ext.data.Store({
id: 'user',
restful: true, // <-- This Store is RESTful
proxy: proxy,
reader: reader,
writer: writer
});
After pressing the "Delete" button, this is the request Ext JS sends:
DELETE http://www.sencha.com/deploy/dev/examples/restful/app.php/users/6 HTTP/1.1
Host: www.sencha.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://www.sencha.com/deploy/dev/examples/restful/restful.html
Content-Length: 10
Cookie: bb_sessionhash=8d75f5e42d576fb695a02bf1d24c9ff1; etc...
{"data":6}
When a request in this format (with the "data" content) is submitted to Google App Engine, it replies with:
400 Bad Request
You can fix this problem, as you guessed, by overriding a method in the HttpProxy class. First, add this code:
// Special HttpProxy that sends no body on DELETE requests
Ext.data.GAEHttpProxy = Ext.extend(Ext.data.HttpProxy, {
doRequest: function(action, rs, params, reader, cb, scope, arg) {
if(this.api[action]['method'].toLowerCase() == "delete") {
delete params.jsonData;
}
Ext.data.GAEHttpProxy.superclass.doRequest.call(this, action, rs, params, reader, cb, scope, arg);
}
});
Then, use this new class ("GAEHttpProxy") instead of HttpProxy in the rest of your code (for instance, when you create the proxy you use in your store shown above). This worked for me, and I hope it works for you!
Although the question is asked 7 years ago and we have sencha 6 now, the problem isn't solved OOTB yet. So here is my working solution:
Ext.define('My.Proxy', {
extend: 'Ext.data.proxy.Rest',
writer: {
type: 'json',
writeAllFields: true, // may be false, as you wish
transform: {
fn: function(data, request) {
return request.config.action === 'destroy' ? null : data;
},
scope: this
}
}
});
We could also do this check: request.config.method === 'DELETE' but for some reason it always returns false. So I recommend to stay with action === 'destroy'