When I make a DELETE request from the client to the server, I come across with the error.
"CSRF Token has been associated to this client" . Response Code : 403 and Response Header
{
"cache-control": "no-cache, no-store, max-age=0, must-revalidate",
"content-length": "45",
"content-type": "text/plain",
"expires": "0",
"pragma": "no-cache",
"referrer-policy": "no-referrer",
"x-content-type-options": "nosniff",
"x-frame-options": "DENY",
"x-xss-protection": "1 ; mode=block"
}
After disabling CSRF from java code as you can see below, the problem is fixed.
http.csrf( ).disable( );
But it is not secure to disable CSRF. Could you please help me not to get "CSRF Token has been associated to this client" error without disabling csrf ?
Thanks
I also faced this issue and the easiest temporary solution I got is to disable web security in browser.
Create a directory
e.g.
/home/user/temp/google-chrome
Start chrome with web security disabled.
google-chrome --user-data-dir=/home/user/temp/google-chrome --disable-web-security
Related
I am writing an app using microsoft graph api. I want to run the command.
https://graph.microsoft.com/v1.0/drives
Unfortunately when I do this with the app I get different results from the app and graph explorer.
https://developer.microsoft.com/en-us/graph/graph-explorer
{
"access-control-allow-origin": "https://graphtryit.azurewebsites.net",
"access-control-expose-headers": "Content-Encoding,Server,Access-Control-Allow-Origin,Access-Control-Expose-Headers,Strict-Transport-Security,request-id,client-request-id,x-ms-ags-diagnostic,x-ms-resource-unit,OData-Version,X-FE-DATA",
"cache-control": "public, must-revalidate, max-age=300",
"client-request-id": "$$ID OMITED$$",
"content-type": "application/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8",
"odata-version": "4.0",
"request-id": "$$ID OMITED$$",
"server": "Microsoft-IIS/10.0",
"strict-transport-security": "max-age=31536000",
"x-ms-ags-diagnostic": "$$OMITED$$"
}
This is the header info for the App
{
'Cache-Control': 'no-store, no-cache',
'Transfer-Encoding': 'chunked',
'Content-Type':'application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8',
'Content-Encoding': 'gzip',
'Vary': 'Accept-Encoding',
'Strict-Transport-Security': 'max-age=31536000',
'request-id': '$$ID OMITED$$',
'client-request-id': '$$ID OMITED$$',
'x-ms-ags-diagnostic': '{"ServerInfo":{"DataCenter":"$$OMITED DIFFERENT SERVER$$"}}',
'OData-Version': '4.0',
'Date': 'Tue, 01 Nov 2022 17:52:48 GMT'
}
Why do you think the two would yield different results? The app has its permissions in place. It's an azure active directory app. The azure request yields one drive. While the graph explorer tool yields all the drives available. Lol new discovery some instances of the graph explorer show what the api does and the other doesn't
New development:
https://learn.microsoft.com/en-us/graph/api/driveitem-list-children?view=graph-rest-1.0&tabs=http#code-try-1
Shows all drives when you input /drives
but https://developer.microsoft.com/en-us/graph/graph-explorer?request=drives&method=GET&version=v1.0&GraphUrl=https://graph.microsoft.com doesn't show all when you enter /drives
{
"cache-control": "no-store, no-cache",
"client-request-id": "$$ID OMITTED$$",
"content-type": "application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8",
"request-id": "$$ID OMITTED$$"
}
Okay I figured it out. The learn site outputs all fake data from
"access-control-allow-origin": "https://graphtryit.azurewebsites.net"
The learn site should not be used to compare to your applications output when debugging your application. Except to get a general idea of what normal output looks like.
I checking how to use IdentityServer4 as I have heard about it a lot. I am trying to make my concepts clear but I am confused:
Access Token: It contains claims that can be used to restrict API access, it contains client info with a token.
Id token: It contains identity info of user, it cannot be used to restrict access to API but it can be used to pass user info just by a token.
I have few questions:
What is difference between ApiResources and IdentityResources?
What is the difference between ApiClaims, ApiScopeClaim and IdentityClaims? And, when and where they are used?
Thanks
Firstly, access tokens do not contain claims.
It is just a JWT token with no claims. You might want to check out the openID specification document. But in short,
Relying Party makes a GET Request to the Token Endpoint which looks something like this:
POST /token/HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-url-encoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code&code=xxxxxxxxxx&redirect_URI=https%3A%2F%2Fclient.example.org%2Fcb
The identity Server should return a response like this:
HTTP/1.1 200 OK
Content-Type: application/json
Cache control: no-store
Pragma: no-cache
{
"access_token": "S1AV32hKG",
"token_type" : "Bearer",
"refresh_token": "xxxxxxxxxxx",
"expires_in": 3600,
"id_token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
As you see the server responds with an access token that can be used to make a request to the userinfo endpoint which contains claims about the user. Claims are nothing but more information regarding the resource owner.
This should be the userinfo endpoint response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"email": "janedoe#example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
Read http://openid.net/specs/openid-connect-core-1_0.html#UserInfoRequest for more information
The error I'm getting from Microsoft Graph API is this
error = {
"code": "BadRequest",
"innerError": {
"date": "2017-04-10T19:37:08",
"request-id": "973641dd-b150-4406-9f3b-fbcf6f7e5aa1"
},
"message": "The MIME type 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' requires a '/' character between type and subtype, such as 'text/plain'."
}
I'm able to successfully get from the endpoint https://graph.microsoft.com/v1.0/me/contacts while using POSTman however going the the scribe-java library OAuthRequest I receive this error.
My request is going to the url https://graph.microsoft.com/v1.0/me/contacts with 2 headers.
Authorization -> Bearer [Token]
Content-Type -> application/json
Try setting the "Accept" header explicitly in your request. POSTman may be defaulting you to [Accept=text/html, image/gif, image/jpeg, *; q=.2, /; q=.2]
Hi I was getting same error when I tried to create a new user on AzureAD with graph api.
I solved my issue that I changed my accept header to "Accept":"text/html, application/json".
For your information
It turns out the scribe-java library doesn't setup the request correctly. Switching to apache HttpClient and HttpGet resolved the issue for me.
Okay, I'm trying to figure out how this Microsoft Authorization API works. I have a native application (iOS) and another web application that I'm intending to run as a daemon in the backend. Both are created in the same Active Directory.
I'm using the the Native application to obtain the Access Token and transferring that to the backend daemon application to obtain an Access Token on behalf of the application using this flow
Now from the backend, I'm sending this request:
grant_type:urn:ietf:params:oauth:grant-type:jwt-bearer
client_id:840c72c1-52fd-4082-bc99-85765cbd3215
resource:https://graph.microsoft.com
client_secret:CGI3d2V4RH1nmiBxR5EkKjsg+woLBG+9bl+H6Aix46U=
assertion:EwAwA8l6BAAU7p9QDpi/D7xJLwsTgCg3TskyTaQAAazJBY1nXVDAMSukxfVB0ojJC1aYhn2+9nPBtQwrq6nNi+6/r8IkJl21tK1y+jBQ9jg7YFbdj4GjRkr1aCjb0w4gWtoLmVYtl+zmg63GZseEJCpUTcFHlBxk1l4bF5F5yTSrfNzZisW9iKdGMmBbdlNDuZPchG+NVdIjS+26h+vu/QADARE82VuIcMictwC/fh6DvDD51v5NfVg+6ZXBy8cbCOnfLx1xut2J0WMjmpN3lqOe0bA7urX9eQH8ElwF3zDy+/7INk4FXSjp+PhCBrCktUiG6fpevpnIVfih2Lbdg1JitYVNY0KYtMkVIU2eerpX996sdw7fhRxR97nJ9AgDZgAACMNVRVFo6MyiAAJe2OJP2XH4Z8OnzUZCrO6L5g99VvkzxrhHrEXohdgWpcBg7XT9Wy3KYOyz1gK+S3vU/iymzAQ3RdR5aAW9YW593XS1W1t/t/0TtgEpcuaWc4ulowoqE0O/8RdQideYHqorg6A5e4/NO2EOz5Zu6bwWXM90edY6dsXGwjIAoCfukY/Ym5N/UuI3nd9KPm1KwTnkAzQmUrG0AH9HiGrqglGScYXD3NWTd881XpjXyVnWan/+Lqd641O/7luCSjhujnkRkGURlWlCTeHdFDcQTqF5e68jL+o5DVDi4/G32OptrpVDxS8CdebjFZQmq4iv9KSqbWZObC8XUplg9goOJQ3gsEvVhuBZB709+j0j3oiUhh0IHoSm5aU3XlbYORppl3Rz3JGPX58k4mU/1ihdr2P2tFw3GQWIuHMrtLUXfb5aBlSjedlP4ziWaoAyWkstmdqploYq8k7a05tC69yb68d1YqfPk2CNNQtKJ2eNb1T0/de04IxocgUisayEuhthAWYy9UuAq+KKos/pbfnriTfgZFkA42vHFTq7VT+HfrDmPG6zM6gkLGf3HXR4mcB74bdY2gSUwBM9dm0qjbN1N+jZ4wpyJhw/sAlUIJko6kyj3KIbN/etPzd6DamsDrSomB5xF9fgdyjl0ll71vCuwij8a46Ulr0iBET4FfmHfws1CzUC
requested_token_use:on_behalf_of
but I'm getting this response header 400 Bad Request:
Cache-Control →no-cache, no-store
Content-Length →447
Content-Type →application/json; charset=utf-8
Date →Sat, 25 Feb 2017 01:41:08 GMT
Expires →-1
P3P →CP="DSP CUR OTPi IND OTRi ONL FIN"
Pragma →no-cache
Server →Microsoft-IIS/8.5
Set-Cookie →x-ms-gateway-slice=003; path=/; secure; HttpOnly
Set-Cookie →stsservicecookie=ests; path=/
Strict-Transport-Security →max-age=31536000; includeSubDomains
X-Content-Type-Options →nosniff
X-Powered-By →ASP.NET
x-ms-request-id →1b12cc35-5ed6-4ebe-8ba8-96e59038a82d
and body:
{
"error": "invalid_request",
"error_description": "AADSTS50027: Invalid JWT token. AADSTS50027: Invalid JWT token. Token format not valid.\r\nTrace ID: 1b12cc35-5ed6-4ebe-8ba8-96e59038a82d\r\nCorrelation ID: ae2fbd5f-f542-4f7e-87a0-fbeb23492266\r\nTimestamp: 2017-02-25 01:41:10Z",
"error_codes": [
50027,
50027
],
"timestamp": "2017-02-25 01:41:10Z",
"trace_id": "1b12cc35-5ed6-4ebe-8ba8-96e59038a82d",
"correlation_id": "ae2fbd5f-f542-4f7e-87a0-fbeb23492266"
}
For some reason, the API thinks that my token in the assertion field is JWT token.
I played around with the Application and the Delegate permissions with no
Any help would be appreciated.
I've got the initial half of an OAuth flow working with the SurveyMonkey API, but when I try to exchange the short-lived authorization code for a long-lived OAuth access token, I get an HTTP 400 response. This is step 3 of the SurveyMonkey OAuth Guide.
Here's a scrubbed version of the full exchange:
POST /oauth/token?api_key=<removed> HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate, compress
Content-Length: 338
Content-Type: application/json; charset=utf-8
Host: api.surveymonkey.net
User-Agent: HTTPie/0.7.2
{
"client_id": "<removed>",
"client_secret": "<removed>",
"code": "dKkIJYnimBli3TMHoTdHoT-zkzkUFzfHeaWJJyPVmrYG35R5Q-jLLU-Y7Fg3BR0n3tVTQ6sAmDnwVxHXSjZVdiYTJ7u7SWbLCKgQa061bKJYXSpRhTsEL0v5GMWcMEBC2vje5UjRHp3SScFQEwIIjHKZH5raC5RQJJh.JYWEOqw8Iy-2Ds7km1zYaHGGlxqu",
"grant_type": "authorization_code",
"redirect_uri": "https://app.hubspotqa.com"
}
HTTP/1.1 400 Bad Request
Cache-Control: no-store
Connection: keep-alive
Content-Length: 96
Content-Type: application/json; charset=UTF-8
Date: Fri, 24 Jan 2014 00:05:53 GMT
SM-Request-ID: 41264d11-b93d-4f8b-ad1a-c656ccfa268b
Server: nginx
{
"error": "invalid_request",
"error_description": "Invalid POST body or Content-Type received."
}
I'm able to reproduce the exact same error using other HTTP clients as well, but I have no trouble manually getting an access token using the SurveyMonkey API console. What am I doing wrong?
Side question: the OAuth guide says that step 3 accepts a redirect_uri but the example Python guide uses redirect_url. Which is the correct parameter? Can I omit it entirely? My server certainly does not care about getting redirected anywhere.
As it turns out, the required Content-Type for this POST is form encoding – application/x-www-form-urlencoded, not JSON.
Note that the documentation does not actually say that anywhere; it's implied by the example usage of the Python requests library.