I have react client that sends get request to my node server using axios, which received in my server after I allowed cors,
and the server passes the request to 3rd side server which I have no access to its configuration at all so I cannot allow cors in that server ,and the request sent with the client Origin of course. For that reason, I get No Access-Control-Allow-Origin error. I read and try many ways to solve that, still without success. Any idea how to solve that?
FYI if I send the request from my server without the client its success.
Edit:
React:
axios.get(host+url).then(...)
Node:
app=express();
....some code here for init auth params(clientId,secret)
and session init
app.get(url,auth.authenticate(failUrl,successUrl);
app.use(auth.init());
The auth.authenticate is libary that after logic that I am not fully aware of taking some params of openid connect authentication, and send get request with all of this params.
At the end of the operation I should be redirected to fail/success url, however I am not even get there.
Related
I added additional API to the Duende IdentityServer 6.2 as described here. Then I tried to access it from a sample App, using typed httpClient using their own library called AccessTokenManagement (aka Identity.Model) pretty much following their simple example. I use Authorization Code flow, everything pretty much simple and default.
It works well until both server and client are on the same dev machine under localhost. As soon as I publish IdentityServer to IIS, the API stops to work, while the rest still works well (I can be authenticated, and I see in the Fiddler that token exchanges work normally).
The call to API consists from two calls:
Calling to /connect/token using refresh token. Server returns access token.
Calling my endpoint using this new access token.
The flow fails on the step 1. Call to /connect/token is already unauthorized and I can't understand why. The "good" and "bad" calls looks the same, I cannot see any differences. Previous call moment ago to /connect/userinfo consists of the same two steps and it works. Logs on both server and client give no clues.
No reverse proxies, just good plain simple URI. Automatic key management is enabled and the keys are in the SQL table, common for dev and published server. Asp.Net Core Data Protection is enabled and keys are also common.
Relevant parts of logs are below. I noticed that "No endpoint entry found for request path" is specific to IdentityServer and it doesn't actually mean that endpoint was not found. It was found but not processed. I also noticed reacher response headers from bad request and log entry about "Cookie signed-in" in good request but not sure what does it mean and whether it's relevant.
I'm running out of ideas.
Bad response from IIS while trying to get new Access Token:
Proper response while developing:
///////Relevant part of log for BAD request
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Token for user test#test.com needs refreshing.
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: cookie was successfully authenticated.
|Duende.AccessTokenManagement.OpenIdConnect.UserTokenEndpointService|refresh token request to: https://auth.mysite.org/connect/token
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Error refreshing access token. Error = Unauthorized
|System.Net.Http.HttpClient.IdsService.ClientHandler|Sending HTTP request POST https://auth.mysite.org/mycontroller/myaction
|System.Net.Http.HttpClient.IdsService.ClientHandler|Received HTTP response headers after 117.7278ms - 401
///////Same part of GOOD request
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Token for user test#test.com needs refreshing.
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: Cookies was successfully authenticated.
|Duende.AccessTokenManagement.OpenIdConnect.UserTokenEndpointService|refresh token request to: https://localhost:5001/connect/token
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: Cookies signed in.
|System.Net.Http.HttpClient.IdsService.ClientHandler|Sending HTTP request POST https://localhost:5001/mycontroller/myaction
|System.Net.Http.HttpClient.IdsService.ClientHandler|Received HTTP response headers after 1994.9611ms - 200
///////Server log during BAD request
Duende.IdentityServer.Hosting.EndpointRouter No endpoint entry found for request path: "/mycontroller/myaction"
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler HandleAuthenticateAsync called
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler AuthenticationScheme: "IdentityServerAccessToken" was not authenticated.
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler AuthenticationScheme: "IdentityServerAccessToken" was challenged.
Okay, found it. Thankfully, looked at Fiddler's WebView and had seen familiar picture!
Then, found this topic. The solution was disabling Basic authentication in IIS settings. Access token request has basic authentication header and it seems like IIS intercepts it. Still a bit unclear why other parts of flow worked.
Background
I have a simple NodeJS server hosted on localhost/Heroku which handles JWT authentication for adding data to the registered user amongst other (unrelated) things.
Here's the GitHub: https://github.com/mlee93dev/pw-keychain-server
I also have a simple Angular2 client on localhost/Heroku for this server:
https://github.com/mlee93dev/pw-keychain-app
Currently, I have my JWT access tokens configured to last only 5 seconds in my server for development purposes.
I have my CORS stuff configured to the best of my knowledge as shown below in server.js:
CORS configuration pic
The Problem
On Postman I test the POST request and I get the expected response - a JWT expiration error:
Postman POST pic
However I don't get the same response on my client - rather, I get a 'JWT must be provided' error:
Client POST pic
As you can see in the pic above, I know I'm actually attaching a token as I console.log it. Here's a pic of the code:
Client POST code pic
So what's confusing me more is that my DELETE request (for logging out) also implements the same x-auth token to request code, and it works in both Postman + client, as seen here:
DELETE error response
DELETE code
So yeah, I'm pretty confused. My guess is I have to configure my CORS some more to allow x-auth header on POST requests specifically somehow? Even though I think it should do that already with my current configuration.
You are providing the body in post request instead of headers.
Angular POST request
So in your post request just do the following
this.http.post(yoururl, {},{headers:new Headers({'x-auth':token})})...
And it should work.
I am using Angular 1.x to POST a verification request to Google's re-captcha as follows:
var post_data = { //prepare payload for request
'secret':'xxxxx',
'response':fields.myRecaptchaResponse
};
$http.post('https://www.google.com/recaptcha/api/siteverify', post_data)
In my console I can see the following error:
XMLHttpRequest cannot load https://www.google.com/recaptcha/api/siteverify. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://igs.dev' is therefore not allowed access. The response had HTTP status code 405.
I have read multiple answers on Stackoverflow, most seem to suggest adding a plugin to Chrome but that is not a solution for my users who will be using the re-captcha to validate a contact form.
Is this a misconfiguration of my server or is my Angular script missing something? I have already ensured that my domain is configured in my re-captcha account.
ReCaptcha is validated on the server-side, not the client side. The CORS error is due to the fact that the ReCaptcha API is not meant to be used by a browser.
You need to send your recaptcha data to your API/server which then verifies it is correct by sending a request to the ReCaptcha API. There are no CORS restrictions when servers make HTTP requests to each other.
See this Tuts tutorial on how the implementation and flow of data works
The end point https://www.google.com/recaptcha/api/siteverify is part of server side validation and not the client side. You should hit this endpoint from your server, not from your client (Angular 1.X).
So the flow may look like this:
At your client side (Angular 1.X) you will be loading the re-captcha widget in your html which will perform the validation and store a hash value in a hidden input field which will be sent to your server along with the other form details when user submits the form. Now at your server side you will hit that endpoint to verify if the validation was successful.
Also, in no case you should be storing your secret at the client side. It should always be maintained at your server side for server-to-server communication purposes.
Read the docs here.
I have a backend using Java which produces JSON for the services, which client will need to login/be authenticated using cookies based (JSESSIONID in Java).
I manage to receive JSESSIONID from server, however concecutive $http.get from client does not include previous generated JSESSIONID which I supposed to be automated handle by $http ?
The case:
Step 1
When I tested my login page using $http.post using valid user id and password, I can get an expected result from my server, I can get a generated JSESSIONID from the server, i.e.:
set-cookie:JSESSIONID=0a624257d0f704840bf6d8c8cc31; Path=/tmh-web; HttpOnly
(pls refer to screenshot in Response Header)
after call Login & been auhthenticated screenshot
Step 2
After been authenticated, when tried to call another URL service which requires authentication, I got an error: "403 Forbidden"
And I suspected this is because $http does not send the JSessionID it has received on Step 1.
(pls refer to screenshot in Request Header, there is no JSessionID has been sent back to server)
call next service which requires authentication
Has anyone experienced this problem with Java as the backend server ?
Use / for path attribute of the cookie.
I'm encountering a pretty strange issue in IE11 where the browser is overriding the Authorization header in my requests even though I am setting it via AngularJS.
Basically, I have an HTTP interceptor registered for all requests that looks like this:
AuthInterceptorService.request = function (config) {
config.headers.Authorization = "Bearer " + bearerToken;
}
This works great in all browsers (even IE under certain conditions). I have my app set up in IIS as allowing anonymous authentication and I have basic/integrated authentication disabled for this subsite, however, the parent configuration has windows authentication eabled.
What is happening occasionally is that the browser will make a request to the root URL for a static file (say, /favicon.ico). This request is denied with a 401. The browser responds with negotiated authentication and gets the favicon. At this point, all other browsers still let my code set the Authorization header, but once this integrated authentication happens in IE, the authorization header seems to get stuck - no matter what my code does, the authorization header is always using integrated authentication. This causes all requests to my API to fail because no Bearer token is present.
I was able to work around the favicon issue by specifying a more local favicon (where static files can be served anonymously), but I am wondering if there is a less hacky solution to this issue. Can I somehow convince IE to let me set the Authorization header even if Windows authentication has taken place on a previous request?
Note: I found this question which seems to be related (maybe the same underlying cause).
If you look at the Negotiate Operation Example of the RFC 4559 document, it involves a pseudo mechanism used by IE to negotiate the choice of security when authenticating with IIS.
The first time the client requests the document, no Authorization
header is sent, so the server responds with
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate
The client will obtain the user credentials using the SPNEGO GSSAPI
mechanism type to identify generate a GSSAPI message to be sent to
the server with a new request, including the following Authorization
header:
C: GET dir/index.html
C: Authorization: Negotiate a87421000492aa874209af8bc028
The server will decode the gssapi-data and pass this to the SPNEGO
GSSAPI mechanism in the gss_accept_security_context function. If the
context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
The client will decode the gssapi-data, pass this into
Gss_Init_security_context, and return the new gssapi-data to the
server.
So, I don't think its possible for you to intermingle while the negotiation takes place as the process is internal