in looking at the sample code, I saw that the logout handler was updating the cookie, so I was assuming that was enough for the next call to secret to be fail and respond as forbidden. Yes, I think I am missing a little of the details for the cookies. As it stands, I hit the endpoints from a browser, and everything works as expected. The handling on logout such that curl requires the -I parameter works as well.
On Thursday, January 25, 2018 at 8:30:27 AM UTC-5, matthe...@gmail.com wrote: > > Normally a web browser would lose the initial cookie value. I think you > may be misunderstanding the use of the gorilla/sessions library (I did even > after inspecting the documentation and source code for awhile). The point > is to store arbitrary values in a store, not provide any form of > authentication. In this example the values are stored as cookies so the > server can be stateless. > > For a service with authentication an approach is to store a secure key as > a cookie (perhaps a gorilla/sessions value) then validate it in every > server call. This way a key could be invalidated by deleting it or marking > it invalid in the server or database where the authentication state > information is kept. > > Matt > > On Wednesday, January 24, 2018 at 6:37:51 PM UTC-6, aiki...@gmail.com > wrote: >> >> Thanks - apparently I wasnt quite getting the -I argument correct with >> logout to make all of it work. >> I still have a little confusion about why the contents of the old cookie >> were not invalidated, to keep a newbie from doing stupid things like I was >> trying. >> >> Thanks again ! >> -Lynch >> >>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
