gatsby-source-graphql does not seem to pass cookie header, how to solve? - apollo

How to pass Cookie headers from gatsby-source-graphql?
I'm using the gatsby-source-graphql (https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-graphql) and recently had to implement AWS Cloudfront Signed Cookies to authorise users to acccess a private staging environment, for this reason the requests to the graphql endpoint, handled by the plugin, need to have the cookie in the request header, which I do by:
{
resolve: 'gatsby-source-graphql',
options: {
cookie: 'var1=val1; var2=val2; '
}
}
The above fails,
ServerParseError: Unexpected token < in JSON at position 0
If disabling Signed Cookies and making the endpoint public, it works.
And, if I keep it private again and test with curl, works:
curl --cookie 'var1=val1; var2=val2; ' graphql_endpoint.com
I tried to figure out why the Cookie header is not passed, but seems that the problem is in a different plugin that the plugin above uses called 'apollo-link-http' (https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-graphql/src/gatsby-node.js)
Meanwhile, looking at the apollo-http-link (https://www.apollographql.com/docs/link/links/http/) and a issue reported here (https://github.com/apollographql/apollo-client/issues/4455), I tried:
{
resolve: 'gatsby-source-graphql',
options: {
typeName: 'FOOBAR',
fieldName: 'foobar',
createLink: (pluginOptions) => {
return createHttpLink({
uri: process.env.GATSBY_GRAPHQL_API_URL,
credentials: 'include',
headers: {
cookie: "CloudFront-Policy=xxxxx_; CloudFront-Key-Pair-Id=xxxxx; CloudFront-Signature=xxxxxxxxxx; path=/;",
},
fetch,
})
},
}
},
Without success, the same error as before.
Also tried to use the fetch options for node-fetch,
{
resolve: 'gatsby-source-graphql',
options: {
typeName: 'FOOBAR',
fieldName: 'foobar',
url: process.env.GATSBY_GRAPHQL_API_URL,
fetchOptions: {
credentials: 'include',
headers: {
cookie: "CloudFront-Policy=xxxxx_; CloudFront-Key-Pair-Id=xxxxx; CloudFront-Signature=xxxxxxxxxx; path=/;",
},
},
}
},
As you can see fetchOptions here (https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-graphql/src/gatsby-node.js)
No success! This is probably a bug.

After spending a lot of time looking at the docs and other reports, I found a solution based on the attempts I've originally posted.
I started by looking at the browser version, and check the cookie header property name to avoid any typos. Which I've determined it should be "Cookie", as most examples I found mention '.cookie', etc.
With that said, I've checked the documentation for all the related packages and source code:
https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-graphql
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-graphql/src/gatsby-node.js
https://www.apollographql.com/docs/link/links/http/
https://github.com/apollographql/apollo-client/issues/4455
Finally, I declared the headers cookie parameter and in a separate property, the options for the node-fetch package:
https://github.com/bitinn/node-fetch
The result:
{
resolve: 'gatsby-source-graphql',
options: {
typeName: 'FOOBAR',
fieldName: 'foobar',
url: process.env.GATSBY_GRAPHQL_API_URL,
headers: {
Cookie: 'CloudFront-Policy=xxxxx_; CloudFront-Key-Pair-Id=xxxxx; CloudFront-Signature=xxxxxxxxxx; path=/;'
},
credentials: 'include',
}
},
What happens above, is that the "credentials include" allow cross-browser origin requests and enables cookies (https://www.apollographql.com/docs/react/networking/authentication/#cookie)
Hope that this helps someone else in the future, as it's not trivial.

Related

How to call a server from localhost VueJS with Axios?

I'm trying to call an AWS hosted API from my VueJS app, which is running on my localhost:8080. I have used this blog post to setup the vue.config.js with this block:
module.exports = {
devServer: {
proxy: 'https://0123456789.execute-api.eu-west-1.amazonaws.com/'
},
...
}
With this in place, I can use this code to make a GET request to an endpoint at that host:
this.$axios
.get('https://0123456789.execute-api.eu-west-1.amazonaws.com/mock/api/endpoint',
{
headers: {
'Content-Type': 'application/json'
}})
This is because I have configured the AWS API Gateway mock endpoint to return these headers for the OPTIONS method:
Access-Control-Allow-Headers: 'Cache-Control,Expires,Pragma,Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'
Access-Control-Allow-Methods: 'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT'
Access-Control-Allow-Origin: '*'
However, I cannot make this call:
this.$axios
.get('https://0123456789.execute-api.eu-west-1.amazonaws.com/lambda/api/function',
{
headers: {
'Content-Type': 'application/json'
}})
This endpoint is a Lambda integration and also has an OPTIONS method with the same headers as above.
Why should both endpoints, configured the same way, have different responses for axios?
UPDATE
As advised by #deniz, I have updated the .env.development file to contain:
VUE_APP_API_URI=https://0123456789.execute-api.eu-west-1.amazonaws.com/
I have also updated the axios requests to:
let url = 'mock/api/endpoint'
let headers = {
headers: {
'Content-Type': 'application/json',
},
}
this.$axios
.get(url, headers)
...and...
let url = 'lambda/api/function'
let headers = {
headers: {
'Content-Type': 'application/json',
},
}
this.$axios
.get(url, headers)
The result I get for the first GET request is:
200 OK
However the second request's response is:
Access to XMLHttpRequest at 'https://0123456789.execute-api.eu-west-1.amazonaws.com/lambda/api/function' from origin 'http://localhost:8080' 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.
Your config for your dev env. as a proxy setup is doing nothing else then pretend to be someone else.
Thats why you dont get any CORS issues when you work with a proxy. its a kinda bottleneck which acts like "i am someone else, not localhost"
module.exports = {
devServer: {
proxy: 'https://0123456789.execute-api.eu-west-1.amazonaws.com/'
},
...
}
from now on all your requests came from this very proxy based URL
https://0123456789.execute-api.eu-west-1.amazonaws.com/
if you try to access the api like this:
this.$axios
.get('https://0123456789.execute-api.eu-west-1.amazonaws.com/lambda/api/function',
{
headers: {
'Content-Type': 'application/json'
}})
you should keep in mind that you are already pretend that your proxy is doing his desguise stuff and still acts like its from a other source.
your URL when you call the API looks like this now, if i am not completely wrong:
https://0123456789.execute-api.eu-west-1.amazonaws.com/https://0123456789.execute-api.eu-west-1.amazonaws.com/lambda/api/function
all you have to do is change the axios url in your request to:
this.$axios
.get('lambda/api/function',
{
headers: {
'Content-Type': 'application/json'
}})
and try again.
UPDATE
VUE_APP_API_URI=https://0123456789.execute-api.eu-west-1.amazonaws.com/
wrap your URL string into quotes, like this and remove the last slash.
VUE_APP_API_URI='https://0123456789.execute-api.eu-west-1.amazonaws.com'
thats a common practice to handle .env vars.
2.
the CORS error you get is a result of not using proxy anymore.
your requesting data from a other source now and this is no allowed on modern browsers like FireFox or Chrome etc.
here you have to handle the server side configs in your API:
https://0123456789.execute-api.eu-west-1.amazonaws.com
because if you go like that you need to give your localhost and your backend the permission to handle requests if the requests are made from different sources, like in your case:
i am localhost and i request data from https://0123456789.execute-api.eu-west-1.amazonaws.com
normally this is forbidden and is a highly risk on security
But the solution is...
As you did before in your AWS API
Access-Control-Allow-Origin: '*' is the important part which handles your "CORS" issues.
make sure it is setup correct and works as intended. maybe play around with that and set localhost instead of * (allow for all)
3.
i highly recommend you to use the proxy way on development and use the non proxy way only for production, and just allow CORS for your frontend only.

how to post using a token in rest-auth with axios? POST http://localhost:8000/rest-auth/password/change/ 401 (Unauthorized)

This is my code in vue,
resetPOST(){
var formData = new FormData();
formData.append('old_password', this.oldPassword);
formData.append('new_password1', this.password1);
formData.append('new_password2', this.password2);
axios.post('http://localhost:8000/rest-auth/password/change/',
{headers: { 'Authorization' : this.token },
data: {
old_password: this.oldPassword,
new_password1: this.password1,
new_password2: this.password2
}
})
},
where the variable 'token' has a value like that : bbf957d27925a860f8c678546cf0425dbf7ddf98
I do not understand why I get this error, if I try the back part I enter the old password, and the two new passwords and it works. For some reason I it isn't taking the token parameter.
Thanks in advance
You are missing the Bearer. Most of the frameworks by default require you to send the authorization in the following format: Bearer <token>.
If you changed the Bearer word to another you should use that one but if you left it to as default in django-rest-auth you have to use the following:
axios.post('http://localhost:8000/rest-auth/password/change/',
{headers: { 'Authorization' : `Bearer ${this.token}` },
data: {
old_password: this.oldPassword,
new_password1: this.password1,
new_password2: this.password2
}
})
I had a similar issue. I realized I was using the same axios instance for users logged into the app which meant using an authentication token. Of course if you are resetting your password you do not have authentication (and therefore a token). Use a different axios instance for your reset password like this:
const instance = axios.create({
baseURL: Store.state.endpoints.baseUrl,
headers: {
'Content-Type': 'application/json'
},
// xhrFields: {
// withCredentials: true
// },
xsrfCookieName:"csrftoken",
xsrfHeaderName:'X-CSRFToken'
})
return instance;
}
Notice there is no auth token and credential are commented out (could probably set to false too). This worked for me.

How to set the request body via Postman's pre-request script?

I use Postman 6.0 to send an HTTP request. To send a request, I use a pre-request script to get a token and put it into the environment so that it will be used in the succeeding requests.
The script below doesn't work because the body is not sent. Is there anything wrong with the script below?
const getTaxAccessToken={
url: 'http://dev.xxx.com:4001/api/v1/portal/account/tax-login',
method: "post",
body: {
'loginIdentity': 'admic',
'password': 'abc123'
},
header: {
'Content-Type': 'application/json'
}
};
pm.sendRequest(getTaxAccessToken, function (err, response) {
console.log("get accesstoken");
console.log(response.access_Token);
pm.environment.set("taxAccessToken", response.access_Token);
});
If the request needs to be of type application/x-www-form-urlencoded:
const options = {
url: 'http://some/url',
method: 'POST',
header: {
'Accept': '*/*',
'Content-Type': 'application/x-www-form-urlencoded',
},
body: {
mode: 'urlencoded',
urlencoded : [
{ key: 'loginIdentity', value: 'admic'},
{ key: 'password', value: 'abc123'},
]
}
};
pm.sendRequest(options, function (err, res) {
// Use the err and res
// ...
pm.environment.set("my-token", res.json().access_token);
});
Postman Javascript API references:
Request
RequestBody
Try this.
body: {
mode: 'raw',
raw: JSON.stringify({'loginIdentity': 'admic', 'password': 'abc123'})
}
For Postman > v8.3.0
With Postman v8.3.0 the update() method was introduced which allows you to set the request body directly from the pre-request script.
For your use case you could simply use:
pm.request.body.update({
mode: 'raw',
raw: JSON.stringify({'loginIdentity': 'admic', 'password': 'abc123'})
});
or even shorter:
pm.request.body.update(JSON.stringify({'loginIdentity': 'admic', 'password': 'abc123'}));
Strings, form-data, urlencoded and other Content-Types
As the title is not specifically tailored to JSON request bodies I thought I'd add some examples for how to handle this for other data as many might find this page when searching on Google and run into this issue for other Content-Types.
Raw
raw in Postman expects a string and therefore you can transmit anything that can be expressed as a string e.g. plain text, HTML, XML, JSON etc. .
// plain text
pm.request.body.update(`Hello World!`);
// HTML
pm.request.body.update(`<html>...</html>`);
// XML
pm.request.body.update(`<xml>...</xml>`);
// JSON
pm.request.body.update(JSON.stringify({ key: `value` }));
URL-encoded
pm.request.body.update({
mode: "urlencoded",
urlencoded: [{
key: "key",
value: "value with spaces and special chars ?/ and umlaute öüä"
}]
});
Form data
pm.request.body.update({
mode: "formdata",
formdata: [{
key: "key",
value: "value with spaces and special chars ?/ and umlaute öüä"
}]
});
GraphQL
pm.request.body.update({
mode: 'graphql',
graphql: {
query: `
query {
hero {
name
friends {
name
}
}
}`
}
});
Example based on GraphQL Tutorial for Fields.
Files from local file system as form-data
pm.request.body.update({
mode: "formdata",
formdata: [
{
key: "file", // does not need to be "file"
type: "file", // MUST be "file"
src: "/C:/Users/MyUser/Documents/myFile.zip"
}
]
})
Please note: This will only work for files in your current working directory. Otherwise you will receive an error like this Form param 'file', file load error: PPERM: insecure file access outside working directory in the Postman console.
You can see where your working directory is when you go to Settings | General | Working Directory. There also is an option Allow reading files outside working directory which you can enable to read files from anywhere, but be aware that this can allow others to steal data from your computer e.g when you execute untrusted collections.

Fetch API with Cookie

I am trying out the new Fetch API but is having trouble with Cookies. Specifically, after a successful login, there is a Cookie header in future requests, but Fetch seems to ignore that headers, and all my requests made with Fetch is unauthorized.
Is it because Fetch is still not ready or Fetch does not work with Cookies?
I build my app with Webpack. I also use Fetch in React Native, which does not have the same issue.
Fetch does not use cookie by default. To enable cookie, do this:
fetch(url, {
credentials: "same-origin"
}).then(...).catch(...);
In addition to #Khanetor's answer, for those who are working with cross-origin requests: credentials: 'include'
Sample JSON fetch request:
fetch(url, {
method: 'GET',
credentials: 'include'
})
.then((response) => response.json())
.then((json) => {
console.log('Gotcha');
}).catch((err) => {
console.log(err);
});
https://developer.mozilla.org/en-US/docs/Web/API/Request/credentials
Have just solved. Just two f. days of brutforce
For me the secret was in following:
I called POST /api/auth and see that cookies were successfully received.
Then calling GET /api/users/ with credentials: 'include' and got 401 unauth, because of no cookies were sent with the request.
The KEY is to set credentials: 'include' for the first /api/auth call too.
If you are reading this in 2019, credentials: "same-origin" is the default value.
fetch(url).then
Programmatically overwriting Cookie header in browser side won't work.
In fetch documentation, Note that some names are forbidden. is mentioned. And Cookie happens to be one of the forbidden header names, which cannot be modified programmatically. Take the following code for example:
Executed in the Chrome DevTools console of page https://httpbin.org/, Cookie: 'xxx=yyy' will be ignored, and the browser will always send the value of document.cookie as the cookie if there is one.
If executed on a different origin, no cookie is sent.
fetch('https://httpbin.org/cookies', {
headers: {
Cookie: 'xxx=yyy'
}
}).then(response => response.json())
.then(data => console.log(JSON.stringify(data, null, 2)));
P.S. You can create a sample cookie foo=bar by opening https://httpbin.org/cookies/set/foo/bar in the chrome browser.
See Forbidden header name for details.
Just adding to the correct answers here for .net webapi2 users.
If you are using cors because your client site is served from a different address as your webapi then you need to also include SupportsCredentials=true on the server side configuration.
// Access-Control-Allow-Origin
// https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api
var cors = new EnableCorsAttribute(Settings.CORSSites,"*", "*");
cors.SupportsCredentials = true;
config.EnableCors(cors);
This works for me:
import Cookies from 'universal-cookie';
const cookies = new Cookies();
function headers(set_cookie=false) {
let headers = {
'Accept': 'application/json',
'Content-Type': 'application/json',
'X-CSRF-Token': $('meta[name="csrf-token"]').attr('content')
};
if (set_cookie) {
headers['Authorization'] = "Bearer " + cookies.get('remember_user_token');
}
return headers;
}
Then build your call:
export function fetchTests(user_id) {
return function (dispatch) {
let data = {
method: 'POST',
credentials: 'same-origin',
mode: 'same-origin',
body: JSON.stringify({
user_id: user_id
}),
headers: headers(true)
};
return fetch('/api/v1/tests/listing/', data)
.then(response => response.json())
.then(json => dispatch(receiveTests(json)));
};
}
My issue was my cookie was set on a specific URL path (e.g., /auth), but I was fetching to a different path. I needed to set my cookie's path to /.
If it still doesn't work for you after fixing the credentials.
I also was using the :
credentials: "same-origin"
and it used to work, then it didn't anymore suddenly, after digging much I realized that I had change my website url to http://192.168.1.100 to test it in LAN, and that was the url which was being used to send the request, even though I was on http://localhost:3000.
So in conclusion, be sure that the domain of the page matches the domain of the fetch url.

Using jquery $.get to call an external web service

I am calling the following jQuery code on page load to test the concept of calling an external web service from the client. The data object in the success callback is always empty. What am I doing wrong?
$.ajax({
url: "http://www.google.com/search",
type: 'GET',
data: { q: "green tea" },
success: function(data) { alert("Data Loaded: " + data) },
dataType: "text/html"
});
It's the same-origin policy you're hitting here, it's specifically in place to prevent cross-domain calls for security reasons. The expected behavior is for the response to be empty here.
You either need to fetch the data via JSONP or get the data via your own domain, your server proxying the request.
It's worth noting Google has a full JavaScript API for searching that you may want to check out for doing this.
browser dont allow you to make cross domain request(a security feature). there is a hack for that with a limitation that you can get only json as response.
----the trick (hack)----
using jquery(or javascript)you create a new script tag and with src="url_of_third_party?", when that request is made you get json from cross site.
jQuery('body').append('<script src="cross_site_url" type="text/javascript"></script>');
or simply you can do this
$.ajax({
url: "http://www.google.com/search",
type: 'GET',
data: { q: "green tea" },
success: function(data) { alert("Data Loaded: " + data) },
dataType: "jsonp",
});
note: dataType=jsonp