<p>I read that I should create a session and store useful data from the user info. My question is should I create a separate session store to store the session ID and user ID? It seems to be duplicate with the provider_gothic_session store in gothic that I have to store the session ID two times in different way. Do I misunderstand the usage of provider_gothic_session? Is provider_gothic_session only used for the authentication process? Afterwards I should create another session ID to keep track of who logged in? I noticed gothic is using the session store in a very strange way.</p>
<hr/>**评论：**<br/><br/>igknighted: <pre><p>Auth protocols tend to expect you to retain some form of token to ask for info. I'm guessing you could just get data you need, hold it in a structure or a volitile keystore like redid for reference while the user is using your service. Permanent service data would need to be stored and pulled local to your service typically based on a unique ID. </p>
<p>When I looked up gothic, I got a ton of teenage angst, so I can only speculate based off what I know about oauth systems. </p>
<p>If you could link me to the gothic API I could take a look for you. </p></pre>whitesoapchicken: <pre><p>here is gothic source code: <a href="https://github.com/markbates/goth/blob/master/gothic/gothic.go" rel="nofollow">https://github.com/markbates/goth/blob/master/gothic/gothic.go</a>
here is gothic example: <a href="https://github.com/markbates/goth/blob/master/gothic/gothic.go" rel="nofollow">https://github.com/markbates/goth/blob/master/gothic/gothic.go</a></p></pre>tdewolff: <pre><p>Gothic needs to to have a store for the state token used in OAuth2, this could be a cookie store (store everything in the cookie, encrypted), or use a session store (store everything on the server, usually persistent using a database or files, but could be in memory as well) which stored the session ID in a cookie on the client. Both are susceptible to CSRF though.</p>
<p>Basically you can pass a <code>gorilla</code> <code>sessions.Store</code>, use that for gothic and then afterwards use it yourself. Personally I used <code>goth</code> itself, the underlying library, as it is more versatile. Look at this for an example: <a href="https://github.com/markbates/goth/blob/master/examples/main.go" rel="nofollow">https://github.com/markbates/goth/blob/master/examples/main.go</a></p>
<p>You don't have to store the session ID yourself. After login you can set some data so you know the user is logged in. Storing the user ID in the session is a good example.</p></pre>whitesoapchicken: <pre><p>Is there any difference in cookie store and session store? I thought they are the same.
The example you provided is also using gothic.
I believe you are trying to tell me to save user ID of users logged in with the session ID gothic created in the cookie store. That is reasonable. I will give it a try. Thanks</p>
<p>edit: I just modified my code and it works just fine. However, since gothic called session.Save() already and so after I called session.Save() to save my own variable, there will be 2 set-cookie headers in response header. It would be great if it can also be solved.</p></pre>tdewolff: <pre><p>Yes, the session store stores a session ID in a cookie and uses this to retrieve the data on the server. Any data stored is never send to the client. With a cookie store all data is stored in the cookie, encrypted to prevent the client from altering it. It's easy to start with the cookie store but you can easily switch later on to another store. There are a lot of implementations for the gorilla store. Personally I prefer the data to stay on the server.</p>
<p><code>goth</code> is the main library and <code>gothic</code> is build on top of that. The example is for goth, not gothic.</p>
<p>Goth will set a cookie when retrieving the auth URL, but you will set a cookie when the auth is complete, namely when you get response from the auth token exchange. This is at two different moments that a cookie is set, not at the same time.</p></pre>whitesoapchicken: <pre><p>Yes I know they are set at two different time. I guess I just have to remove the duplicate set-cookie header manually.</p></pre>
