Go web development: Brower can't set cookie - go

I want to set cookie in Go:
func rememberMe(w http.ResponseWriter,username string) {
expiration := time.Now().AddDate(0,1,0) // cookie will be stored for 1 month
cookie := http.Cookie{Name: "rememberMe",Value: username,Expires: expiration}
http.SetCookie(w,&cookie)
fmt.Println("Cookie has been set.")
}
The response was quite fine and there was a Set-Cookie filed:
Access-Control-Allow-Headers: Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Origin: *
Content-Length: 10
Content-Type: text/plain; charset=utf-8
Date: Thu, 20 Sep 2018 12:48:20 GMT
Set-Cookie: rememberMe=buddy; Expires=Sat, 20 Oct 2018 12:48:19 GMT
But when I used Chrome developer tools to check the cookie, there was no cookie. I am confused about this problem.

Thanks for #Peter. The thing is cross-origin.My back end runs at locolhost:8088 and front end runs at localhost:8080. So I did some configuration in both back end and front end. Here's the back end code:
func SetupResponse(w *http.ResponseWriter, r *http.Request) {
(*w).Header().Set("Access-Control-Allow-Origin", "http://localhost:8080")
(*w).Header().Set("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE")
(*w).Header().Set("Access-Control-Allow-Headers", "Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization")
(*w).Header().Set("Access-Control-Allow-Credentials", "true")
}
I use axios in front end:
this.$axios.create({ withCredentials: true })
.get("http://localhost:8088/api/")
.then((response) => {
//....
}).catch((error) => {
console.log(error);
});

Related

Axios is not sending cookies

I have two apps, the server-side app which is written in Laravel and the client-side app, written in VueJS. The vue app consumes the api provided by the laravel app.
The auth flow:
The user attempts to log in, the server sends two tokens to the client, a) access_token and b) refresh_token upon successful login. The server also sends the refresh token in the form of an httpOnly cookie to the client so that when the access token is expired, it can be refreshed using the refresh token from the cookie.
The problem:
When the user logs in, in the response, the server sends the following Set-Cookie header:
Set-Cookie:
refresh_token=tokenvalue;
expires=Mon, 04-Nov-2019 09:13:28 GMT; Max-Age=604800;
path=/v1/refresh; domain=http://app.test; httponly; samesite=none
This means that I expect the cookie to be sent to the server whenever there is a request to the /v1/refresh endpoint. However, the cookie is not present in the request. (I've logged $request->cookie('refresh_token') in controller but it logs null).
This whole token refreshing mechanism is handled in a vuex action:
export function refreshToken({commit}, payload) {
return new Promise((resolve, reject) => {
// axios.defaults.withCredentials = true;
// here, payload() function just converts the url to:
// "http://app.test/v1/refresh"
axios.post(payload('/refresh'), {}, {
withCredentials: true, transformRequest: [(data, headers) => {
delete headers.common.Authorization;
return data;
}]
}).then(response => {
let token = response.data.access_token;
localStorage.setItem('token', token);
commit('refreshSuccess', token);
resolve(token);
}).catch(err => reject(err));
});
}
As you can see, I've set the withCredentials config to true. I am also sending the Access-Control-Allow-Credentials: true from the server. Here is my cors middleware:
public function handle($request, Closure $next)
{
$whiteList = ['http://localhost:8080'];
if (isset($request->server()['HTTP_ORIGIN'])) {
$origin = $request->server()['HTTP_ORIGIN'];
if (in_array($origin, $whiteList)) {
header('Access-Control-Allow-Origin: ' . $request->server()['HTTP_ORIGIN']);
header('Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS');
header('Access-Control-Allow-Headers: Origin, Content-Type, Authorization');
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Expose-Headers: Content-Disposition');
}
}
return $next($request);
}
I don't know what have I done wrong. My PHP version is: 7.3.5. Here are the request headers of /v1/refresh endpoint:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,bn;q=0.8
Connection: keep-alive
Content-Length: 15
Content-Type: application/x-www-form-urlencoded
Host: app.test
Origin: http://localhost:8080
Referer: http://localhost:8080/products
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36
...and the response headers:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, Content-Type, Authorization
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: http://localhost:8080
Access-Control-Expose-Headers: Content-Disposition
Cache-Control: no-cache, private
Connection: keep-alive
Content-Type: application/json
Date: Mon, 28 Oct 2019 09:40:31 GMT
Server: nginx/1.15.5
Transfer-Encoding: chunked
X-Powered-By: PHP/7.3.5
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59
I don't know the inner-workings of browser's cookie storing mechanism, I also don't know if an httpOnly cookie can be found in the filesystem, but in despair, to know whether the browser is indeed saving the cookie, I googled and found that cookies are stored in ~/Library/Application Support/Google/Chrome/Default/Cookies file, which is an SQLite file. I opened that file and searched for my cookie 🍪, but it wasn't there either (maybe httpOnly cookies are stored somewhere else?).
Now, my question is, how do I retrieve the cookie from the client-side app?
Since your Vue App and Laravel (API) has different HOST, it will not working.
You can re-check your server response:
Set-Cookie: refresh_token=tokenvalue; expires=Mon, 04-Nov-2019 09:13:28 GMT; Max-Age=604800; path=/v1/refresh; domain=http://app.test; httponly; samesite=none
It sets the cookie to http://app.test, not http://localhost:8080. So, there is no refresh_token cookie set in your http://localhost:8080.
The very typical solution is:
You need to use subdomain, and let your cookie set to the
domain=.app.test (whole domain). I mean, you need to make sure
Laravel and Vue under the same domain.
You don't need to get the refresh_token from cookie again in your Laravel app. First, you just need to save your refresh_token you get from API, to the either localStorage or cookie at your Vue App. Then, just send your refresh_token via forms (form-data). Finally, get your refresh_token via $request->get('refresh_token').
Here is the example, just to illustrate what i mean for the second solution.
Let's assume (typically) the http://app.test/api/login would response:
{
"token_type": "Bearer",
"expires_in": 31622399,
"access_token": "xxx",
"refresh_token": "xxx"
}
import Cookies from 'js-cookie'
async login() {
const { data } = await axios.post('http://app.test/api/login', {
email: 'hi#app.test',
password: 'secret',
})
const refreshToken = data.refresh_token
Cookies.set('refresh_token', refreshToken)
},
async refreshToken() {
const refreshToken = Cookies.get('refresh_token')
const response = await axios.post('http://app.test/api/refresh-token', {
refresh_token: refreshToken,
})
}

Certain cookies are blocked cross domain when using an ajax request

I'm using a react app running on localhost:3000 which makes ajax requests to our website. We recently switched our authentification system from using WordPress authentification to https://github.com/delight-im/PHP-Auth.
Since then, using the same settings inside ajax and on our web server, our authentification cookies are not sent cross domain. However, it's working when requesting them from the same domain.
Our request:
fetchLoginStatus = () => {
const ajax = new XMLHttpRequest();
ajax.withCredentials = true;
ajax.open("POST", "https://our-website.com/src/php/checkLoggedIn.php");
ajax.onload = () => {
const response = JSON.parse(ajax.responseText);
};
ajax.send();
};
Our request headers (from localhost:3000):
:authority: my-website.com
:method: POST
:path: /src/php/checkLoggedIn.php
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
content-length: 0
cookie: plesk-items-per-page; plesk-sort-field, phpMyAdmin; databases-active-list-state-collapsed; plesk-list-type; io=R_dL3fjUEYe64ykHAAAp; isAsyncProgressBarCollapsed=true; PLESKSESSID; plesk-sort-dir;
origin: https://localhost:3000
referer: https://localhost:3000/
Our response headers (we are running an nginx server):
access-control-allow-credentials: true
access-control-allow-headers: origin, x-requested-with, content-type
access-control-allow-methods: PUT, GET, POST, DELETE, OPTIONS access-`
control-allow-origin: https://localhost:3000
cache-control: no-store, no-cache, must-revalidate
content-encoding: br
content-type: text/html; charset=UTF-8
date: Sun, 10 Mar 2019 15:26:08 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT pragma:
no-cache server: nginx
set-cookie: PHPSESSID=someId;
path=/; SameSite=Lax status: 200
vary: Accept-Encoding
x-powered-by: PleskLin`
When I don't send the request cross-domain PHPSESSID is inside the cookies of my request headers. However when I send the request from localhost:3000 it's not there.
Does somebody know how I can send the PHPSESSID from localhost too?
Thanks for any help in advance!
Asked the same question inside the github repository and the owner solved it.
https://github.com/delight-im/PHP-Auth/issues/154
Solution:
vendor/delight-im/auth/src/UserManager.php
Replace Session::regenerate(true); with Session::regenerate(true, null);
vendor/delight-im/auth/src/Auth.php
Replace #Session::start(); with #Session::start(null);
Replace Session::regenerate(true); with Session::regenerate(true, null);
After $cookie->setSecureOnly($params['secure']); append $cookie-
>setSameSiteRestriction(null); in all three (!) occurrences

XMLHttpRequest CROS issues when uploading(post) files to S3 from browser and redirecting to a custom url

This case is easy to understand, and I have paste enough information about the problem. Thank you for your patience. :)
There is a case that I use JQuery File Upload (UI) to upload images to AWS S3 directly from client browser, here is the post data:
AWSAccessKeyId: xxxxxx,
key: filename.jpg,
Policy: xxxxxx,
Signature: xxxxx,
acl: 'private',
success_action_redirect:'http://example.org/test',
'Content-Type': x.type
the policy and signature are totally fine, and the image has been uploaded as well.
but there is problem when redirect to the pre-defined url http://example.org/test:
XMLHttpRequest cannot load https://s3-eu-west-1.amazonaws.com/mybucket/.
The request was redirected to 'http://localhost:8000/test?bucket=mybucket&key=filename.jpg&etag=xxxxxxxx',
which is disallowed for cross-origin requests that require preflight.
I paste the http request and response for https://s3-eu-west-1.amazonaws.com/mybucket/:
Request:
POST /mybucket/ HTTP/1.1
Host: s3-eu-west-1.amazonaws.com
Connection: keep-alive
Content-Length: 298856
Origin: http://localhost:8000
X-CSRF-TOKEN: H5HRwmtwCVAxIgmAvM8YL5bgayuDyyQV2UKUqnhT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryhI9Z5605GrykYXvT
Accept: application/json, text/javascript, */*; q=0.01
Content-Disposition: attachment; filename="xxxxxxx"
Referer: http://localhost:8000/xxxxxxxx
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Response:
HTTP/1.1 303 See Other
x-amz-id-2: g1VdA6dwEHl+y/C8nSTD7qzxL7gX9o3c0JV7Cj7cKYDeUPNvlrkRzaJEz4PtNFCPZhOAhA8pqzw=
x-amz-request-id: 48C7F5DB54CCEF65
Date: Thu, 29 Oct 2015 02:35:31 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
ETag: "772d776abbc1bb619d208c92d4b986c9"
Location: http://localhost:8000/test?bucket=mybucket&key=filename.jpg&etag=xxxxxxxx
Content-Length: 0
Server: AmazonS3
And for the redirect endpoint http://example.org/test, which is implemented in Laravel 5.1. Here are the relative routes:
Route::group(['prefix' => 'test'], function () {
Route::options('/', function(){
return response(null, 204)
->header('Access-Control-Allow-Origin' , '*')
->header('Access-Control-Allow-Credentials', 'true')
->header('Access-Control-Allow-Methods', 'POST, GET, OPTIONS')
->header('Access-Control-Allow-Headers', 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type')
->header('Access-Control-Max-Age', '1728000')
->header('Content-Type', 'text/plain charset=UTF-8')
->header('Content-Length', '0');
});
Route::get('/', function () {
return response('test', 200)
->header('Access-Control-Allow-Origin' , '*')
->header('Access-Control-Allow-Credentials', 'true')
->header('Access-Control-Allow-Methods', 'POST, GET, OPTIONS')
->header('Access-Control-Allow-Headers', 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type');
});
});
When GET http://example.org/test directly, here is the HTTP response headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Access-Control-Allow-Methods:POST, GET, OPTIONS
Access-Control-Allow-Origin:*
Cache-Control:no-cache
Connection:close
Content-Type:text/html; charset=UTF-8
Date:Thu, 29 Oct 2015 02:47:51 GMT
Host:localhost:8000
Any body can help me figure out where is the problem? Thanks!

Ajax Request header field Key is not allowed by Access-Control-Allow-Headers

Trying to build a DNN Service Framework WebAPI but I'm having trouble consuming it with CORS. I have all of the appropriate headers (I think) but it still doesn't seem to be working.
Error:
XMLHttpRequest cannot load http://www.dnndev.me/mysite/builder/API/echo?message=Hello+World&_=1412707749275. Request header field Key is not allowed by Access-Control-Allow-Headers.
Request Headers:
Remote Address: 127.0.0.1:80
URL: http://www.dnndev.me/mysite/builder/API/echo?message=Hello
Request Method: OPTIONS
Status Code: 200 OK
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Access-Control-Request-Headers: accept, key
Access-Control-Request-Method: GET
Connection: keep-alive
Host: www.dnndev.me
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
Response Headers:
Access-Control-All-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Content-Length: 13
Content-Type: application/json; charset=utf-8
Date: Tue, 07 Oct 2014 18:49:10 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/7.5
Generally, this error would be caused by not having the appropriate header in 'Access-Control-All-Headers'. However, I am sending the correct response to allow ajax to continue with its request. It simply refuses to.
Here is my ajax call to the method:
$.ajax({
type: 'GET',
url: 'http://www.dnndev.me/mysite/builder/API/echo',
dataType: 'json',
data: { message: 'Hello' },
crossDomain: true,
headers: { 'Key': 'Bearer 7680ff6e-1362-4236-a9cd-c6bc8b6f13ea' },
success: function (result) { console.log(result); }
});
Probably obvious, but this only happens on cross domain requests and only when I include the custom header (therefore procing ajax to do an OPTIONS).
Your server responds with the following custom header to the preflight request:
Access-Control-All-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
whereas if you (or the person who wrote this server) read carefully about CORS he should have responded with:
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
Now the client client could go ahead and use the Key custom header.
This being said, Bearer is quite specific to OAuth 2 which is sent throughout the Authorization header. Using Key seems like a terrible violation of RFCs and stuff and a wheel reinvention kinda.
Please note the typo in Nyx's question and Darin's answer ('ow' missing). So it's
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
and it resolves the error message 'Request header field some-header-field is not allowed by Access-Control-Allow-Headers in preflight mode', if sent as an answer to the browser's OPTION request.
Add this to your server response headers :
header('Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token , Authorization');

Spring MVC does not handle RequestMethod.OPTIONS

I am in the context of a Rest API. As I am performing cross domain request, I need to send back the header "Access-Control-Allow-Origin".
I have a controller such:
#Controller
#RequestMapping("/api")
public class PackageManagerRestController {
#RequestMapping(method = RequestMethod.OPTIONS, value = "/test")
public void commonOptions(HttpServletResponse theHttpServletResponse) throws IOException {
theHttpServletResponse.addHeader("Access-Control-Allow-Headers", "origin, content-type, accept, x-requested-with");
theHttpServletResponse.addHeader("Access-Control-Max-Age", "60"); // seconds to cache preflight request --> less OPTIONS traffic
theHttpServletResponse.addHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
theHttpServletResponse.addHeader("Access-Control-Allow-Origin", "*");
}
#RequestMapping(method = RequestMethod.GET, value = "/test")
public void getPtions(HttpServletResponse theHttpServletResponse) throws IOException {
theHttpServletResponse.addHeader("Access-Control-Allow-Headers", "origin, content-type, accept, x-requested-with");
theHttpServletResponse.addHeader("Access-Control-Max-Age", "60"); // seconds to cache preflight request --> less OPTIONS traffic
theHttpServletResponse.addHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
theHttpServletResponse.addHeader("Access-Control-Allow-Origin", "*");
}
}
If I run a test with GET, the result is as expected:
$ curl -i -X GET http://localhost:8081/api/test
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Access-Control-Allow-Headers: origin, content-type, accept, x-requested-with
Access-Control-Max-Age: 60
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Wed, 16 Apr 2014 08:18:38 GMT
However, if I send the request with OPTIONS, the controller never handles the request:
$ curl -i -X OPTIONS http://localhost:8081/api/test
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Content-Length: 0
Date: Wed, 16 Apr 2014 08:19:56 GMT
Anyone has any clue of why I am receiving this "default response" and why I cannot customize it ?
For default Spring DispatcherServlet supports GET, HEAD, POST, PUT, PATCH and DELETE only; if you want to support TRACE and OPTIONS you have to put "dispatchOptionsRequest" and "dispatchTraceRequest" properties to "true"; check here docs.spring.io/spring/docs/4.0.3.RELEASE/javadoc-api
In order to support OPTIONS too in your web.xml you have to put this:
<init-param>
<param-name>dispatchOptionsRequest</param-name>
<param-value>true</param-value>
</init-param>
By adding it I can handle OPTIONS:
~$ curl -i -X OPTIONS http://localhost:8180/sample/api/test
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Access-Control-Allow-Headers: origin, content-type, accept, x-requested-with
Access-Control-Max-Age: 60
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Content-Length: 0
Date: Wed, 16 Apr 2014 08:44:55 GMT
Angelo
according to the last answer
I resolve my problem
#RequestMapping(value = "/**",method = RequestMethod.OPTIONS)
public String getOption(HttpServletResponse response,Model model)
{
response.setHeader("Access-Control-Allow-Origin","*");
response.setHeader("Access-Control-Allow-Methods", "GET,PUT,POST,DELETE");
return "";
}
and we need to add something to the dispacherservlet
<init-param>
<param-name>dispatchOptionsRequest</param-name>
<param-value>true</param-value>
</init-param>
and this is over

Resources