I have a project in Angular 2.4.0 where I want to call endpoints from a Symfony 3 REST API. Both projects are launched locally. To get rid of CORS errors in Http calls in Angular, I set some proxy rules as follows :
{
"/api/*": {
"target": "http://myapi.dev:8000",
"secure": false,
"changeOrigin": true,
"pathRewrite": {"^/api" : ""},
"logLevel": "debug"
}
}
The first step is the authentication with Google OAuth, so I open a new popup window (in my Angular project) :
window.open('api/connect/google', '_blank', 'location=yes,height=570,width=520,scrollbars=yes,status=yes');
Then I chose a Google account to authenticate with, then the API close the popup window automatically when successfully authenticated.
Then I call the API again to get the current logged-in user :
get(): Observable<User> {
return this.http.get('api/user')
.map((response: Response) => response.json())
.catch((error: any) => Observable.throw(error));
}
The problem is that the API throws the following :
Request URL:http://localhost:2222/api/user
Request Method:GET
Status Code:302 Found
Remote Address:127.0.0.1:2222
Access-Control-Allow-Origin:*
cache-control:no-cache, private
connection:close
content-type:json
date:Wed, 22 Mar 2017 10:20:32 GMT
location:http://myapi.dev:8000/login
server:nginx/1.11.10
transfer-encoding:chunked
x-debug-token:128b90
x-debug-token-link:http://myapi.dev:8000/_profiler/128b90
x-powered-by:PHP/7.1.3
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:PHPSESSID=18c73caec383e91904dfd239d1a95faa
Host:localhost:2222
Pragma:no-cache
Referer:http://localhost:2222/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
It seems the API don't know I'm already authenticated and tries to redirect me to the /login route for every other Http calls I want to make.
The API works as following :
/login is a twig page with a link to /connect/google (the Google OAuth)
/connect/google allows you to choose one Google Account to authenticate with
If you call any API endpoint without being authenticated, it redirects you to /login
If you're authenticated, you can call every API endpoint
If I try all above Angular Http calls directly into the browser (eg: http://myapi.dev:8000/connect/google, http://myapi.dev:8000/user) everything works well.
I really have no idea where this issue comes from.
As you said in comments, Angular app is hosted on http://localhost:2222/, but api is hosted on http://myapi.dev:8000. Those two origins are completely different. It means that when myapi.dev will begin session, set cookie, it will be unavailable on localhost. Browser is not allowed to send cookies from different origins (due to CORS). That's why api doesn't see your session id key.
Possible ways to overcome problem:
Store both apps (angular and api) on the same origin (it means same domain, same protocol, and same port) - it's the easiest way.
Catch session ID cookie value (just after it will be set) and store it inside sessionStorage. Next, create Angular's request interceptor which will add SESSION cookie to all requests which're going to myapi.dev
Related
I'm trying to set up a new instance of a simple App Engine which communicate with a backend-function hosted on Google Cloud Function. The App Engine is protected with IAP, and the Google Cloud Function is private only. The GAE use Angular Framework and GCF use Node 14 with Express
.
I can't access to my GCF from the App Engine because the requests are blocked by CORS.
Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I tried the popular solutions on the web :
Use the cors librairie on the GCF. So I had on my GCF
var cors = require('cors')
app.use(cors(cors({ credentials: true, origin: true })))
And I also add this line for every request
res.set('Access-Control-Allow-Origin', '*')
Add the http-header on my app.yaml
handlers:
- url: /(.*\.[A-Za-z0-9]{1,4})$
static_files: dist/\1
upload: dist/(.*\.[A-Za-z0-9]{1,4})$
http_headers:
Access-Control-Allow-Origin: "*"
- url: /(.*)$
static_files: dist/index.html
upload: dist/index.html
http_headers:
Access-Control-Allow-Origin: "*"
But I still get the same error message.
EDIT : so the first problem was due to an authentication issue, that why the error have the same response. So I decided to deploy the 2 apps on App Engine to simplify communication between the 2 services.
You can now have full access to the HTTP Request/Responses by setting
the appropriate CORS headers as per this documentation.
Just so you know the reason for the error you are facing, it is
because when your web browser is calling a service that is in a
different/cross domain, it doesn’t make a HTTP request right away, it
rather starts with making an OPTIONS request( a preflight request)
and compares the value of Access-Control-Allow-Origin header in the
result with the current domain i.e. it checks for this (req.method
=== 'OPTIONS') in the headers and if the header value matches the host, the actual call is made, otherwise the action is stopped and
the error as the one above is thrown.
To have a thorough understanding of the above concept, have a look at
this stackoverflow answer and read this article for more insights.
I'm building a React app that allows users to login with Google and then connects to a webhook/3rd Party service in Realm. The service should only return data that the users own.
I've set up the OAuth 2 with Google and can get back access_token for a user and I then pass it in the header (I've also tried the URL params) to the webhook. But I get an error back saying:
400 "no authentication methods were specified" - "Invalid Parameter".
After much testing, I've identified that it must be a Realm issue - but I can't figure out what.
I've tried authenticating with Google in Postman and sending a request from there like this:
GET <incoming_webhook URL>
Request Headers
Authorization: Bearer <access_token>
User-Agent: PostmanRuntime/7.26.10
Accept: */*
Host: us-east-1.aws.webhooks.mongodb-realm.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
But I get the same error.
In Realm I have "Google" enabled as an authentication providers (and the authentication works just not the authorization through the webhook).
Per https://docs.mongodb.com/realm/services/configure/service-webhooks/#configure-user-authentication, you can choose email/password, an API key, or a custom JWT token. I don't know whether you can use google login directly to a webhook, but you're probably better off making a realm function instead.
Regarding the error no authentication methods were specified, you can specify the type of authentication method (using a custom JWT as an example) by either:
putting it in the header:
Header: jwtTokenString, Value: eyJhbGci.....
OR
by including it as part of the webhook body:
{
"jwtTokenString":"eyJhbGci...",
"mydata": "my data value"
}
If you try to use both methods, you get a multiple authentication methods used error. HTTP Bearer tokens in the header, etc, are useless here.
For an API Key, instead of jwtTokenString, use api-key; or email`password` for email\password authentication.
I found these methods of providing authenticating information really unintuitive and the documentation very unclear.
I am using Hasura to interface with a graphql endpoint on my django project using Graphene. I need to ensure that the user has authenticated for all calls to the graphql endpoint. In a typical rest api all you'd need to do is pass a session cookie back and forth and I would assume it's the same process with GraphQL.
I can interface with the graphql endpoint just fine using Postman, first authenticating with a rest endpoint then passing the cookies I received when making calls to the graphql endpoint. When I copy the cookie to hasuras headers I am not receiving any cookies on the backend. This is effectively what I am setting the header to on hasura:
Set-Cookie : session=iLCJhbGciOiJIUzeyJ0eXAiOiJKV1QI1NiJ9.eyJzZXNzaW9uX2lkIjoiMzUzYWI5M2EtZmVmMi00ZjkyLTllYmItYjlmMDM3ODFkNzMwIiwiZXhwaXJlc19pbiI6IjIwMjAtMDUtMTJUMTk6MTM6MDkuOTc5MjA3WiIsImZpbmdlcnByaW50IjoiT3RoZXIgLyBPdGhlciAvIE90aGVyIiwiY3JlYXRlZF9hdCI6IjIwMjAtMDUtMTJUMTg6NTg6MDkuOTg1NzQ0WiIsImlwIjoiMTI3LjAuMC4xIiwidXNlciI6IjYwNjYwMjgyLTI1ZGEtMTFlYS04YjAzLTRhN2I0YjZmMmYyYSJ9.WCm3GbbLXk-2kbhvKSUpNS-8ggHbEHrDi7YPuLtpvik; path=/; domain=localhost; HttpOnly; Expires=Wed, 13 May 2020 02:58:09 GMT;
I am trying to confirm I have cookies by inserting this code into a resolver but all that is printed is an empty dict.
print(info.context.COOKIES)
I am using Hasura in Heroku and running a Vuejs + Node.js application, I'm creating a cookie(HttpOnly, Secure) with a JWT as value, had setup the hasura HASURA_GRAPHQL_JWT_SECRET to:
{"type":"HS256", "key": "secret","header":{"type": "Cookie", "name": "namecookie" } }
Always returnig 'no cookie name in the header JWT', I'm sending a fetch from Vue direct to Hasura, I want to! even if it is unsafe. but it does not work.
error :"405 not allowed Method" in post method type call in request command vue
i need call api function with content-type:application/json and post Method type with request command in vue ,but browser add preflight request with options method type and it causes this error :"405 not allowed Method"
var options = {
method: "POST",
url: "http://api.sample.com/login",
headers: {
"Access-Control-Request-Method":"POST",
"cache-control": "no-cache",
"content-type": "application/json",
},
body: '{ Username: "demo", Password: "demo", Domain: "test" }'
};
request(options, function(error, response, body) {
if (error) throw new Error(error);
body.data;
alert("ok");
});
The OPTIONS call is done whenever you do a cross-origin request. This means the domain your application is running on is different from the domain where the api is. A pre-flight request is mandatory for these requests, because the browser needs to figure out if you are allowed to do these requests. A 405 error means that the server thinks you are not allowed to make that request.
To solve this problem you can move your api to the same domain as your frontend. Please note that it cannot be on a subdomain.
A different way of solving this, is by sending back the correct headers. In your case you seem to at least miss the Access-Control-Allow-Methods response header. Make sure to send this header and either dynamically figure out which methods are allowed, or do something like the following. That would allow the most common methods to work.
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
In the comments you said that you do not have control over the api, and as such cannot change the response header. In that case your best bet is to contact whoever maintains the api and ask how to best use their api.
In the comments you said that this worked fine when you did the same thing in ASP.NET. ASP.NET is a server-side language, which means that requests in that context do not have a concept of "cross-origin". Cross-origin only comes into play in the browser, where the application runs on an actual domain.
Assuming you can set up a proxy on your application domain, you can also create a proxy that proxies all requests to the api you actually want to communicate with. You would deploy your domain on https://example.com and do your requests to https://example.com/api/endpoint. Your proxy will listen for requests that begin with https://example.com/api and proxy it to https://whatever.the.api.is/ with the appropriate endpoint and data.
Please keep in mind that while some api's might just be configured incorrectly, a lack of cross-origin response headers might just mean that the api is nog meant to be consumed through the browser. Part of this could be that the request contains a secret that should not be exposed to users that use your application, but should instead only be on the server. Using a proxy in that case would set you up for impersonation attacks, because you would expose the secret to your application, but defeat the cross-origin headers by making it appear to the application that the api is on the same domain.
I have the following scenario:
1) Azure Mobile Services API
2) Custom Authentication
3) Web and Xamarin Clients
4) Small test harness (.NET app using MSTest)
With the custom authentication, I can login from both the browser and the unit test and get back the appropriate userID and token.
Something like this:
var user = await Connect.MobileClient
.InvokeApiAsync<LoginRequest, MobileServiceUser>(
"CustomLogin", new LoginRequest()
{
username = username,
password = password
});
I then do the following:
Connect.MobileClient.CurrentUser = user;
Debugging makes it clear that the userId and the MobileServicesAuthenticationToken are correctly set.
When, I invoke the POST on my controller, however, I'm getting tossed out with unauthorized after the Initialize method on the controller executes.
A few notes:
1) Everything works swimmingly if I do the POST from the "try this out" (after registering, logging in, and pasting the token value in the X-ZUMO-AUTH header).
2) Likewise, no issue if I remove the
[AuthorizeLevel(AuthorizationLevel.User)]
from the controller class or method (tried both).
Here is the failing post (from Fiddler):
POST https://anapi.azure-mobile.net/tables/Organization__systemproperties=__createdAt%2C__updatedAt%2C__version%2C__deleted HTTP/1.1
X-ZUMO-FEATURES: TT
X-ZUMO-INSTALLATION-ID: dfddf760-ecef-49cb-8197-2faaaaa11502
X-ZUMO-APPLICATION: aaaaaauJOUyfFjjPmZpobTybtaaaaaa
Accept: application/json
User-Agent: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.30324.0)
X-ZUMO-VERSION: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.30324.0)
Content-Type: application/json; charset=utf-8
Host: anapi.azure-mobile.net
Content-Length: 110
Expect: 100-continue
Accept-Encoding: gzip
{"OrganizationId":0,"Name":"International Bozo, Inc.","Address":"Dallas, Texas","Accounts":null,"Courses":null}
The "try this" HTTP POST includes the X-ZUMO-AUTH header with the appropriate token.
You need to set the client.currentUser property before calling the client.invokeAPI method (it appears from your question you are doing the other order)
The X-ZUMO-AUTH header is then populated from the user.MobileAuthenticationToken
as shown here:
https://github.com/Azure/azure-mobile-services/blob/master/sdk/Managed/src/Microsoft.WindowsAzure.MobileServices/Http/MobileServiceHttpClient.cs#L566-L569