I was able to get the sessionToken using username and password. But, after that I want to create the session using POST call as follows in AngularJS. The angular (entire web app) is hosted on AWS S3.
var session_data = { 'sessionToken' : My_session_Token};
$http({
method: 'POST',
url: 'https://myorg.okta.com/api/v1/sessions',
data: session_data,
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json',
}
}).then(function(response) {
console.log(response);
});
The error I am getting is
XMLHttpRequest cannot load https://myorg.okta.com/api/v1/sessions. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://s3.amazonaws.com' is therefore not allowed access.
I have already added the CORS Allow origin header in Okta as well as S3 bucket.
When I try doing the following through terminal
curl -v -X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{
"sessionToken": "my_session_Token"
}' "https://myorg.okta.com/api/v1/sessions"
First time I get
{"errorCode":"E0000005","errorSummary":"Invalid session","errorLink":"E0000005","errorId":"oaefADOnPONTDidUZYyrVc5rQ","errorCauses":[]}MAC-S014568:~
second time, because of sessionToken is one time use only I get following error
{"errorCode":"E0000004","errorSummary":"Authentication failed","errorLink":"E0000004","errorId":"oaeI-KKSO-iRGSR1gmyUjBS8g","errorCauses":[]}MAC-S01
I don't think the problem is because of the CORS header (Allow origin) as I have already added the origin.
Also, I cannot use SSWS {api_TOKEN} as my application is in angular and its risky to expose the api token.
Any help will be highly appreciated
Okta doesn't support POSTing to /api/v1/sessions to set a cookie in the browser. For a simple use case, you can use the redirect flow:
window.location = 'https://myorg.okta.com/login/sessionCookieRedirect?token={sessionToken}&redirectUrl={redirectUrl}';
All the allowed methods of setting a cookie using a sessionToken are listed here: http://developer.okta.com/use_cases/authentication/session_cookie
Related
I am using JavaScript fetch() with following options:
window.fetch(path, {
method: 'PUT',
headers: {'Content-Type': 'application/json'},
mode: 'cors',
credentials: 'include',
redirect: 'follow',
referrerPolicy: 'no-referrer',
cache: 'no-cache',
body: JSON.stringify(data)
})
but I get error:
Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.
and my Access-Control-Allow-Headers has wildcard *.
It works without Credentials
It works fine if I don't add credentials: include and turn OFF auth on API server.
It works without Content-Type
It works fine if I don't add headers: {'Content-Type': 'application/json'}, and keep auth ON on API server. It means it is sent with text/plain;UTF-8 but content is still JSON.
Headers
Headers from my API server:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Expose-Headers: *
http://localhost:3000 is where is my front-end app running on.
Hints
If i get this error, devTools in Chrome are not able to show me response headers (Access-Control-Allow-Headers etc.) and request headers shows Provisional headers are shown with only content-type: application/json in it and in General there is not method: PUT (there is not method at all). So it looks like Chrome stopped it before firing.
Server is on different domain (intern web) and is running on http with SameSite: None without Secure but I have disabled security Cookies without SameSite must be secure in Chrome to walkaround it in development mode.
Is there any relationship between credentials, content-type and PUT? Is it possible to send PUT with credentials and application/json? If it is not possible - how should I send data with PUT method? FormData which are allowed content-type for cors are not supported by PUT.
See the MDN documentation for Access-Control-Allow-Headers:
The value * only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name * without special semantics. Note that the Authorization header can't be wildcarded and always needs to be listed explicitly.
You need to specify the headers you want to allow explicitly.
Changing Access-Control-Allow-Headers from wildcard * to explicit Content-Type did the trick for me.
This question already has answers here:
No 'Access-Control-Allow-Origin' header is present on the requested resource—when trying to get data from a REST API
(26 answers)
How does the 'Access-Control-Allow-Origin' header work?
(19 answers)
Closed 2 years ago.
Im trying to use an API for my website. I am trying to send a POST request with JSON data. But when I try to send the request I get an error code. I have tried sending the request with curl and that works without any problem.
Access to XMLHttpRequest at 'https://mpc.getswish.net/qrg-swish/api/v1/prefilled' from origin 'http://192.168.0.90' 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.
Curl command
curl --data '{"format":"svg","size":300,"message":{"value":"test","editable":true},"amount":{"value":100,"editable":false},"transparent":true}' --header "Content-Type: application/json" --output output.png --request POST https://mpc.getswish.net/qrg-swish/api/v1/prefilled
I have enabled Access-Control-Allow-Origin in apache configuration.
<VirtualHost *:80>
ServerAdmin webmaster#localhost
ServerName web
ServerAlias web
DocumentRoot /var/www/web
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Header always set Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header always set Access-Control-Allow-Methods "GET,POST,PUT,OPTIONS"
</VirtualHost>
And this is my jQuery code
$.ajax({
type: 'POST',
url: 'https://mpc.getswish.net/qrg-swish/api/v1/prefilled',
data: '{"format":"svg","size":300,"message":{"value":"test","editable":true},"amount":{"value":100,"editable":false},"transparent":true}',
headers: { 'Access-Control-Allow-Origin': '*' },
success: function(data) { alert('data: ' + data); },
contentType: "application/json",
dataType: 'json'
});
Thanks!
If you are using an API that enforces CORS, then it probably means they don't want you to call it from a web browser at all. What you need to do is make your own back-end which your front-end will talk to. So your AJAX call needs to go to your own back-end, which calls the API, and sends the result back. The back-end can call the API without CORS limits. Only web browsers enforce CORS for security measures.
I'm trying to make authorized requests to LinkedIn's API after using OAuth2.0 to sign in users. I keep getting errors regarding the CORS policy and need help in sending the correct headers so that I no longer get these errors.
I've tried including a couple different 'Access-Control-Request' headers but I keep getting the same error. I'm pretty sure it has something to do with the 'Authorization' header I'm sending to the API, but this header is required from the documentation to receive the correct information.
https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin/context#step-1-configure-your-application
The code I'm using to make this call is shown below...
async function getProfileData(accessToken, expiresIn) {
const requestUrl = `https://api.linkedin.com/v2/me`;
const response = await fetch(requestUrl, {
method: 'GET',
headers: {
'Host': 'api.linkedin.com',
'Connection': 'Keep-Alive',
'Authorization': `Bearer ${accessToken}`,
'Origin': REDIRECT_URI,
'Access-Control-Request-Method': 'GET',
'Access-Control-Request-Headers': 'Content-Type, Authorization'
}
});
return response;
}
The accessToken, in this case, comes from a previous network call using an authorization code from a previous step. Everything before this is working and I'm getting a response with what I assume to be a valid access token.
Previously, I was getting an error saying that my access token wasn't valid even though I followed the documentation step-by-step to retrieve it. I'm not sure if this is the same issue or not, but I can't see a reason why I would have an invalid token (the token wasn't expired and I never rejected the permissions on sign-in).
The response I'm expecting to get back from the call is the basic profile data from the user that is signed in but instead, I get this:
OPTIONS https://api.linkedin.com/v2/me 401
getProfileData # app.js:74
(anonymous) # app.js:50
Access to fetch at 'https://api.linkedin.com/v2/me' from origin 'https://simple-linkedin-login2.netlify.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
I am setting up onelogin and I came to this step where I must send one more POST request with the given code from the first GET request (https://developers.onelogin.com/openid-connect/api/authorization-code-grant).
They are saying I must send the POST request to this URL https://.onelogin.com/oidc/token and I am sending the request with Angular 7.
const headers = new HttpHeaders({
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic <base64 encoded ${environment.clientId}:${environment.clientSecret}`
});
const options = {
headers: headers
};
const body = {
grant_type: 'authorization_code',
code: code,
redirect_url: this.getCallbackURL(),
client_id: environment.clientId,
client_secret: environment.clientSecret
};
return this.httpClient.post('https://openid-connect-eu.onelogin.com/oidc/token', body, options).toPromise();
But then I get this error:
Access to XMLHttpRequest at 'https://openid-connect-eu.onelogin.com/oidc/token' from origin 'https://my-site-name.com' 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.
NOTE: replaced with openid-connect-eu as I am in the EU as described in the documentation.
Javascript prevents POST calls to other domains at the browser level unless they are expressly permitted by the service (and OneLogin doesn't permit this, for security reasons)
I'll add that doing this authentication flow via Javascript is not considered secure since anyone could intercept the clientID and Secret from your code.
For javascript apps, I'd recommend using the Implicit OIDC flow, which is documented here:
https://developers.onelogin.com/openid-connect/api/id-token
OneLogin also has sample code for this:
https://github.com/onelogin/onelogin-oidc-node/tree/master/2.%20Implicit%20Flow
I am prototyping a very simple webapp. I installed Couch 1.3.1 today and created a database. I am attempting to save a document to my local couch (localhost:5984) with a POST from a client browser also on localhost, but different port (6789)
var dbIp = "http://localhost:5984/commute";
var data = {state:0,timestamp:"faketime"};
$.ajax({
type: 'POST',
crossDomain: true,
contentType: "application/json",
url: dbIp,
data: data,
success: function(result) {
console.log(result);
}
});
I get:
XMLHttpRequest cannot load http://localhost:5984/commute-tracker. Origin http://localhost:6789 is not allowed by Access-Control-Allow-Origin.
I have modified the local.ini to enable CORS as outlined in the couchdb spec with
[httpd]
enable_cors = true
[cors]
origins = *
[cors]
methods = GET, POST, PUT, DELETE
I can see all of these changes reflected in the config file in futon. I have also tested the database with a curl:
curl -X POST localhost:5984/commute -H "Content-Type: application/json" -d '{"tags":"sure","name":"made it"}'
The curl works just fine, but I can't make a similar POST in the browser because of Access Control Allow Origin. What else am I missing, or what can I change to make this POST possible?
Going about this trying to do cross-domain, whether it's CORS or JSONP is not ideal.
Since you actually do control both the web server instance and the couchdb instance (I'm assuming you have admin rights to the server) I'd recommend using a reverse proxy to serve couchdb as an endpoint for the main web app.
If you're using Apache mod_proxy will allow you to do this, or nginx is another great HTTP reverse proxy server...inserting a config directive like:
ProxyPass /couch_db/ http://www.localhost:5984/ (for mod_proxy)
would let you post to http://localhost:6789/couch_db/commute