


How to resolve cookie not being transferred between localhost ports in Go chat application?
I'm having an issue with cookie-based token authentication in my chat application. I'm using go backend with standard network libraries to add token to response cookie. When a user is password authenticated (via post to the /login path on the authentication server), the response cookie should contain the access token used to generate the api token and the refresh token used to regenerate the access token.
This is a markup file that contains the structure of the application services in my development environment. Each server runs on localhost using go net/http on sequential ports (unrelated services are not shown).
auth_server ( dependencies [] url (scheme "http" domain "localhost" port "8081") listenaddress ":8081" endpoints ( /jwtkeypub ( methods [get] ) /register ( methods [post] ) /logout ( methods [post] ) /login ( methods [post] ) /apitokens ( methods [get] ) /accesstokens ( methods [get] ) ) jwtinfo ( issuername "auth_server" audiencename "auth_server" ) ) message_server ( dependencies [auth_server] url (scheme "http" domain "localhost" port "8083") listenaddress ":8083" endpoints ( /ws ( methods [get] ) ) jwtinfo ( audiencename "message_server" ) ) static ( dependencies [auth_server, message_server] url (scheme "http" domain "localhost" port "8080") listenaddress ":8080" )
This is the code to set the cookie when logging in. This happens after password check
// set a new refresh token refreshtoken := s.jwtissuer.stringifyjwt( s.jwtissuer.minttoken(userid, s.jwtissuer.name, refreshtokenttl), ) kit.sethttponlycookie(w, "refreshtoken", refreshtoken, int(refreshtokenttl.seconds())) // set a new access token accesstoken := s.jwtissuer.stringifyjwt( s.jwtissuer.minttoken(userid, s.jwtaudience.name, accesstokenttl), ) kit.sethttponlycookie(w, "accesstoken", accesstoken, int(accesstokenttl.seconds())) }
func sethttponlycookie(w http.responsewriter, name, value string, maxage int) { http.setcookie(w, &http.cookie{ name: name, value: value, httponly: true, maxage: maxage, }) }
Here's how I access the cookie when the user requests the api token. If an error is returned, the handler calls the gettokenfromcookie() function and responds with 401. The error in this case is "http: The named cookie does not exist"
func gethttpcookie(r *http.request, name string) (*http.cookie, error) { return r.cookie(name) } func gettokenfromcookie(r *http.request, name string) (jwt.jwt, error) { tokencookie, err := gethttpcookie(r, name) if err != nil { // debug log.println(err) return jwt.jwt{}, err } return jwt.fromstring(tokencookie.value) }
After the 200 response from the login endpoint, the page redirects to the main application page. On this page, make a request to the authentication server to receive the API token used to connect to the live chat messaging server. As you can see from the log output on the auth server, the access token cookie was not received with the request, so the request returned a 401 code.
2023/05/19 02:33:57 get [/jwtkeypub] - 200 2023/05/19 02:33:57 get [/jwtkeypub] - 200 2023/05/19 02:34:23 post [/login] - 200 2023/05/19 02:34:23 http: named cookie not present {{ } { } []} http: named cookie not present 2023/05/19 02:34:23 get [/apitokens?aud=msgservice] - 401
I believe the problem is that I'm using localhost and the browser doesn't transfer the cookie from locahost:8080 to localhost:8081. I'm planning on implementing some kind of impersonation authentication that bypasses reading the development environment's cookies to solve this problem, but I'm not sure if that's actually the cause of my problem. Just wanted to take another look and see if I could get it to work without having to do this.
Update: I've looked at the network tab in the dev tools: The image shows that the response after login returns cookies, but they are not then sent to the authentication server on port 8081. After getting the 200 response for the login I also looked at the cookie storage and even after that there were no cookies receiving them in the response. I'm using firefox's private mode to access the site. Note that even though I set maxage in the go code, the cookie does not contain maxage, which seems to be an issue.
Update: This is the har file after login. You can see that the response has max-age, but then it doesn't show up in the cookies tab.
{ "log": { "version": "1.2", "creator": { "name": "Firefox", "version": "113.0.1" }, "browser": { "name": "Firefox", "version": "113.0.1" }, "pages": [ { "startedDateTime": "2023-05-19T12:16:37.081-04:00", "id": "page_1", "title": "Login Page", "pageTimings": { "onContentLoad": -8105, "onLoad": -8077 } } ], "entries": [ { "pageref": "page_1", "startedDateTime": "2023-05-19T12:16:37.081-04:00", "request": { "bodySize": 31, "method": "POST", "url": "http://0.0.0.0:8081/login", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Host", "value": "0.0.0.0:8081" }, { "name": "User-Agent", "value": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0" }, { "name": "Accept", "value": "*/*" }, { "name": "Accept-Language", "value": "en-US,en;q=0.5" }, { "name": "Accept-Encoding", "value": "gzip, deflate" }, { "name": "Referer", "value": "http://localhost:8080/" }, { "name": "Content-Type", "value": "text/plain;charset=UTF-8" }, { "name": "Content-Length", "value": "31" }, { "name": "Origin", "value": "http://localhost:8080" }, { "name": "DNT", "value": "1" }, { "name": "Connection", "value": "keep-alive" } ], "cookies": [], "queryString": [], "headersSize": 370, "postData": { "mimeType": "text/plain;charset=UTF-8", "params": [], "text": "{\"username\":\"a\",\"password\":\"a\"}" } }, "response": { "status": 200, "statusText": "OK", "httpVersion": "HTTP/1.1", "headers": [ { "name": "Access-Control-Allow-Origin", "value": "*" }, { "name": "Set-Cookie", "value": "refreshToken=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJQMmY2RHg1RWxlYTF5THBUaVpEejBaS3Z1dk1FUkFPZEtBVGkwNDZSc2JNPSIsImF1ZCI6InN0ZWVsaXgiLCJpc3MiOiJzdGVlbGl4IiwiZXhwIjoiMTY4NTExNzc5NyIsImp0aSI6IjIwMUQzODZDNTRBQzlEOUMwRjdCODFBMDVDNDlFQTE1In0.SbxFgEAtZbh0zS-SXZmrVW9iLk-cFz6HcDMU0FHNl-K9BwCeb_boc5igEgImMSYK-NBVQZh1km7YknE-jkBWyF0rIYjSnTzjNUHHwMnn0jE1N-dtEfNRnF1OT0R2bxPSz8gmhtJ3B839xa-jh9uMPMkXEB8BYtABgPH1FqBdijHPUtRVKq6C3ulVleurp2eyF8EHpGLc9rr5wBYSFBk0HQ3FNjjUxfRQLDnzl2xYovoQ2em4grExnkdACxCSpXNtF5bQ7lCnEZyf7-CehrRNwZCpteGKj5ux_wrX_nxma3OEWwrlatML_j-e420TM1tub0C9Ymyt0bMugHw8vaiOGA; Max-Age=604800; HttpOnly" }, { "name": "Set-Cookie", "value": "accessToken=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJQMmY2RHg1RWxlYTF5THBUaVpEejBaS3Z1dk1FUkFPZEtBVGkwNDZSc2JNPSIsImF1ZCI6InN0ZWVsaXgiLCJpc3MiOiJzdGVlbGl4IiwiZXhwIjoiMTY4NDUxNDE5NyIsImp0aSI6IjY2NjU1QjAyNTc4NkRBRTE1M0VDNDI3MzBGMjMxQ0FGIn0.cIs6KGjRGTHaWX_uFTts_V2a3YcBb7LA0jNOBTZeyDmpPQgRlcABnuYkWUIdjUdR6VYnDitFRV-XK2ZSq6Pk_ZgyfvJ3yRzvWGYjXMu7Nq7MLpVvUh9mLKSbKvlqunW6YVamHSCAbYS8-D_pY9fpWxIcXw0qbwA2XfTdzr0Mrw7ntrkdyK7O1QqWamnEHCmpLfJ2XJlQsU0KaD8FjkL76pO3lWmrca3VYnTmjP1Oo1HEhbK3nImtrNeL2khAyb8ns8ROj2HX41IDNK1aHWPfn9J04pgH3AfBfcwhhqZkrKjTVFQAkSYzuvjKPWOfpgYmBMw3Y5nG_PDf-zlvVPrdpQ; Max-Age=1200; HttpOnly" }, { "name": "Date", "value": "Fri, 19 May 2023 16:16:37 GMT" }, { "name": "Content-Length", "value": "0" } ], "cookies": [ { "name": "refreshToken", "value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJQMmY2RHg1RWxlYTF5THBUaVpEejBaS3Z1dk1FUkFPZEtBVGkwNDZSc2JNPSIsImF1ZCI6InN0ZWVsaXgiLCJpc3MiOiJzdGVlbGl4IiwiZXhwIjoiMTY4NTExNzc5NyIsImp0aSI6IjIwMUQzODZDNTRBQzlEOUMwRjdCODFBMDVDNDlFQTE1In0.SbxFgEAtZbh0zS-SXZmrVW9iLk-cFz6HcDMU0FHNl-K9BwCeb_boc5igEgImMSYK-NBVQZh1km7YknE-jkBWyF0rIYjSnTzjNUHHwMnn0jE1N-dtEfNRnF1OT0R2bxPSz8gmhtJ3B839xa-jh9uMPMkXEB8BYtABgPH1FqBdijHPUtRVKq6C3ulVleurp2eyF8EHpGLc9rr5wBYSFBk0HQ3FNjjUxfRQLDnzl2xYovoQ2em4grExnkdACxCSpXNtF5bQ7lCnEZyf7-CehrRNwZCpteGKj5ux_wrX_nxma3OEWwrlatML_j-e420TM1tub0C9Ymyt0bMugHw8vaiOGA" }, { "name": "accessToken", "value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJQMmY2RHg1RWxlYTF5THBUaVpEejBaS3Z1dk1FUkFPZEtBVGkwNDZSc2JNPSIsImF1ZCI6InN0ZWVsaXgiLCJpc3MiOiJzdGVlbGl4IiwiZXhwIjoiMTY4NDUxNDE5NyIsImp0aSI6IjY2NjU1QjAyNTc4NkRBRTE1M0VDNDI3MzBGMjMxQ0FGIn0.cIs6KGjRGTHaWX_uFTts_V2a3YcBb7LA0jNOBTZeyDmpPQgRlcABnuYkWUIdjUdR6VYnDitFRV-XK2ZSq6Pk_ZgyfvJ3yRzvWGYjXMu7Nq7MLpVvUh9mLKSbKvlqunW6YVamHSCAbYS8-D_pY9fpWxIcXw0qbwA2XfTdzr0Mrw7ntrkdyK7O1QqWamnEHCmpLfJ2XJlQsU0KaD8FjkL76pO3lWmrca3VYnTmjP1Oo1HEhbK3nImtrNeL2khAyb8ns8ROj2HX41IDNK1aHWPfn9J04pgH3AfBfcwhhqZkrKjTVFQAkSYzuvjKPWOfpgYmBMw3Y5nG_PDf-zlvVPrdpQ" } ], "content": { "mimeType": "text/plain", "size": 0, "text": "" }, "redirectURL": "", "headersSize": 1347, "bodySize": 1748 }, "cache": {}, "timings": { "blocked": 0, "dns": 0, "connect": 0, "ssl": 0, "send": 0, "wait": 13, "receive": 0 }, "time": 13, "_securityState": "insecure", "serverIPAddress": "0.0.0.0", "connection": "8081" } ] } }
The response appears to have cookies, but they are not being saved.
And the next request to the authentication server does not add any cookies.
Correct answer
tl;dr:
- Cookies are not shared between
0.0.0.0
andlocalhost
. - Both session cookies and normal cookies can be shared between
http://localhost:8080
andhttp://localhost:8081
. - Requests sent from the
http://localhost:8080/
page tohttp://localhost:8081/
will be considered a cross-domain request. -
fetch
Cross-origin requests sent should be initialized withcredentials: 'include'
to allow the browser to save the cookie.
har shows that the url of the web page is http://localhost:8080/
, but the login endpoint is http://0.0.0.0:8081/login
. Cookies for 0.0.0.0
will not be shared with localhost
.
You can run the following demo to observe the behavior:
-
Run the demo:
go run main.go
; -
Open
http://localhost:8080/
in your browser. This page will do the following:- It sends a request to
http://0.0.0.0:8081/login1
(the purpose is to verify that the cookie of0.0.0.0
is not shared withlocalhost
; - It sends a request to
http://localhost:8081/login2
(the purpose is to verify that the session cookie will be betweenhttp://localhost:8080
andhttp:/ /localhost:8081
shared between; - It sends a request to
http://localhost:8081/login3
(the purpose is to verify that normal cookies will be sent betweenhttp://localhost:8080
andhttp: //shared between localhost:8081
; - It navigates to
http://localhost:8080/resource
and the server will dump the request. Indicates that this header is sent to the server:cookie:login2=localhost-session; login3=localhost
.
- It sends a request to
Comments: credentials: 'include'
requires the access-control-allow-origin
header to be set to the exact origin (which means *
will be denied) with the access-control-allow-credentials
header set to true
.
package main import ( "fmt" "log" "net/http" "net/http/httputil" ) func setHeader(w http.ResponseWriter, cookieName, cookieValue string, maxAge int) { w.Header().Set("Access-Control-Allow-Origin", "http://localhost:8080") w.Header().Set("Access-Control-Allow-Credentials", "true") http.SetCookie(w, &http.Cookie{ Name: cookieName, Value: cookieValue, MaxAge: maxAge, HttpOnly: true, }) } func main() { muxWeb := http.NewServeMux() // serve the HTML page. muxWeb.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { _, err := w.Write([]byte(page)) if err != nil { panic(err) } })) // Dump the request to see what cookies is sent to the server. muxWeb.Handle("/resource", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { dump, err := httputil.DumpRequest(r, false) if err != nil { panic(err) } _, _ = w.Write(dump) })) web := &http.Server{ Addr: ":8080", Handler: muxWeb, } go func() { log.Fatal(web.ListenAndServe()) }() muxAPI := http.NewServeMux() muxAPI.Handle("/login1", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { setHeader(w, "login1", "0.0.0.0", 1200) })) muxAPI.Handle("/login2", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { setHeader(w, "login2", "localhost-session", 0) })) muxAPI.Handle("/login3", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { setHeader(w, "login3", "localhost", 1200) })) api := &http.Server{ Addr: ":8081", Handler: muxAPI, } go func() { log.Fatal(api.ListenAndServe()) }() fmt.Println("Open http://localhost:8080/ in the browser") select {} } var page string = ` <!DOCTYPE html> <html> <body> <script type="module"> async function login(url) { const response = await fetch(url, { mode: 'cors', credentials: 'include', }); } await login('http://0.0.0.0:8081/login1'); await login('http://localhost:8081/login2'); await login('http://localhost:8081/login3'); window.location = '/resource'; </script> </body> </html> `
The above is the detailed content of How to resolve cookie not being transferred between localhost ports in Go chat application?. For more information, please follow other related articles on the PHP Chinese website!

The main differences between Golang and Python are concurrency models, type systems, performance and execution speed. 1. Golang uses the CSP model, which is suitable for high concurrent tasks; Python relies on multi-threading and GIL, which is suitable for I/O-intensive tasks. 2. Golang is a static type, and Python is a dynamic type. 3. Golang compiled language execution speed is fast, and Python interpreted language development is fast.

Golang is usually slower than C, but Golang has more advantages in concurrent programming and development efficiency: 1) Golang's garbage collection and concurrency model makes it perform well in high concurrency scenarios; 2) C obtains higher performance through manual memory management and hardware optimization, but has higher development complexity.

Golang is widely used in cloud computing and DevOps, and its advantages lie in simplicity, efficiency and concurrent programming capabilities. 1) In cloud computing, Golang efficiently handles concurrent requests through goroutine and channel mechanisms. 2) In DevOps, Golang's fast compilation and cross-platform features make it the first choice for automation tools.

Golang and C each have their own advantages in performance efficiency. 1) Golang improves efficiency through goroutine and garbage collection, but may introduce pause time. 2) C realizes high performance through manual memory management and optimization, but developers need to deal with memory leaks and other issues. When choosing, you need to consider project requirements and team technology stack.

Golang is more suitable for high concurrency tasks, while Python has more advantages in flexibility. 1.Golang efficiently handles concurrency through goroutine and channel. 2. Python relies on threading and asyncio, which is affected by GIL, but provides multiple concurrency methods. The choice should be based on specific needs.

The performance differences between Golang and C are mainly reflected in memory management, compilation optimization and runtime efficiency. 1) Golang's garbage collection mechanism is convenient but may affect performance, 2) C's manual memory management and compiler optimization are more efficient in recursive computing.

ChooseGolangforhighperformanceandconcurrency,idealforbackendservicesandnetworkprogramming;selectPythonforrapiddevelopment,datascience,andmachinelearningduetoitsversatilityandextensivelibraries.

Golang and Python each have their own advantages: Golang is suitable for high performance and concurrent programming, while Python is suitable for data science and web development. Golang is known for its concurrency model and efficient performance, while Python is known for its concise syntax and rich library ecosystem.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

ZendStudio 13.5.1 Mac
Powerful PHP integrated development environment

VSCode Windows 64-bit Download
A free and powerful IDE editor launched by Microsoft

MantisBT
Mantis is an easy-to-deploy web-based defect tracking tool designed to aid in product defect tracking. It requires PHP, MySQL and a web server. Check out our demo and hosting services.

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.