For a new node.js project I&#39;m working on, I&#39;m thinking about switching over from a cookie based session approach (by this, I mean, storing an id to a key-value store containing user sessions in a user&#39;s browser) to a token-based session approach (no key-value store) using JSON Web Tokens (jwt).

The project is a game that utilizes socket.io - having a token-based session would be useful in such a scenario where there will be multiple communication channels in a single session (web and socket.io)

How would one provide token/session invalidation from the server using the jwt Approach? 

I also wanted to understand what common (or uncommon) pitfalls/attacks I should look out for with this sort of paradigm. For example, if this paradigm is vulnerable to the same/different kinds of attacks as the session store/cookie-based approach.

So, say I have the following (adapted from [this][1] and [this][2]):

Session Store Login:

    app.get(&#39;/login&#39;, function(request, response) {
        var user = {username: request.body.username, password: request.body.password };
        // Validate somehow
        validate(user, function(isValid, profile) {
            // Create session token
            var token= createSessionToken();

            // Add to a key-value database
            KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});

            // The client should save this session token in a cookie
            response.json({sessionToken: token});
        });
    }

Token-Based Login:

    var jwt = require(&#39;jsonwebtoken&#39;);
    app.get(&#39;/login&#39;, function(request, response) {
        var user = {username: request.body.username, password: request.body.password };
        // Validate somehow
        validate(user, function(isValid, profile) {
            var token = jwt.sign(profile, &#39;My Super Secret&#39;, {expiresInMinutes: 60});
            response.json({token: token});
        });
    }

--

A logout (or invalidate) for the Session Store approach would require an update to the KeyValueStore 
database with the specified token.

It seems like such a mechanism would not exist in the token-based approach since the token itself would contain the info that would normally exist in the key-value store.


  [1]: http://blog.auth0.com/2014/01/15/auth-with-socket-io/
  [2]: http://coderead.wordpress.com/2012/08/16/securing-node-js-restful-services-with-jwt-tokens/

Invalidating JSON Web Tokens

I read that [sending cookies with cURL](https://stackoverflow.com/questions/7181785/send-cookies-with-curl) works, but not for me.

I have a REST endpoint like this:

    class LoginResource(restful.Resource):
        def get(self):
            print(session)
            if &#39;USER_TOKEN&#39; in session:
                return &#39;OK&#39;
            return &#39;not authorized&#39;, 401

When I try to access the endpoint, it refuses:

    curl -v -b ~/Downloads/cookies.txt -c ~/Downloads/cookies.txt http://127.0.0.1:5000/
    * About to connect() to 127.0.0.1 port 5000 (#0)
    *   Trying 127.0.0.1...
    * connected
    * Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0)
    &gt; GET / HTTP/1.1
    &gt; User-Agent: curl/7.27.0
    &gt; Host: 127.0.0.1:5000
    &gt; Accept: */*
    &gt;
    * HTTP 1.0, assume close after body
    &lt; HTTP/1.0 401 UNAUTHORIZED
    &lt; Content-Type: application/json
    &lt; Content-Length: 16
    &lt; Server: Werkzeug/0.8.3 Python/2.7.2
    &lt; Date: Sun, 14 Apr 2013 04:45:45 GMT
    &lt;
    * Closing connection #0
    &quot;not authorized&quot;%

Where my `~/Downloads/cookies.txt` is:

    cat ~/Downloads/cookies.txt
    USER_TOKEN=in

and the server receives nothing:

    127.0.0.1 - - [13/Apr/2013 21:43:52] &quot;GET / HTTP/1.1&quot; 401 -
    127.0.0.1 - - [13/Apr/2013 21:45:30] &quot;GET / HTTP/1.1&quot; 401 -
    &lt;SecureCookieSession {}&gt;
    &lt;SecureCookieSession {}&gt;
    127.0.0.1 - - [13/Apr/2013 21:45:45] &quot;GET / HTTP/1.1&quot; 401 -

What is it that I am missing?


How to use cURL to send Cookies?

What is the difference between creating cookies on the server and on the client? Are these called server side cookies and client side cookies? Is there a way to create cookies that can only be read on the server or on the client?

What is the difference between server side cookie and client side cookie?

How do I resolve the problem of losing a session after a redirect in PHP?

Recently, I encountered a very common problem of losing session after redirect. And after searching through this website I can still find no solution (although [this][1] came the closest). 

**Update**

I have found the answer and I thought I&#39;d post it here to help anyone experiencing the same problem.


  [1]: https://stackoverflow.com/questions/2037316/php-session-destroyed-lost-after-header

PHP session lost after redirect

I&#39;m trying to understand more about PHP [Session Fixation][1] and hijacking and how to prevent these problems. I&#39;ve been reading the following two articles on Chris Shiflett&#39;s website: 

 - [Session Fixation][2]
 - [Session Hijacking][3]

However, I&#39;m not sure I&#39;m understanding things correctly. 

To help prevent session fixation, is it enough to call `session_regenerate_id(true);` after successfully logging someone in? I think I understand that correctly.

He also talks about using tokens passed along in urls via `$_GET` to prevent session hijacking. How would this be done exactly? I&#39;m guessing when someone logs in you generate their token and store it in a session variable, then on each page you&#39;d compare that session variable with the value of the `$_GET` variable?

Would this token need to be changed only once per session or on each page load? 

Also is there a good way of preventing hijacking without having to pass a value along in the URLs? This would be a lot easier.


  [1]: https://www.owasp.org/index.php/Session_fixation
  [2]: http://shiflett.org/articles/session-fixation
  [3]: http://shiflett.org/articles/session-hijacking

PHP Session Fixation / Hijacking

I recently created a new Laravel project and was following along the guide on Authentication. When I visit either my login or register route, I get the following error:

    ErrorException in Request.php line 775:
    Session store not set on request. (View: C:\Users\Matthew\Documents\test\resources\views\auth\register.blade.php)

I haven&#39;t edited any core Laravel files, I&#39;ve only created the views and added the routes to my routes.php file

    // Authentication routes
    Route::get(&#39;auth/login&#39;, [&#39;uses&#39; =&gt; &#39;Auth\AuthController@getLogin&#39;, &#39;as&#39; =&gt; &#39;login&#39;]);
    Route::post(&#39;auth/login&#39;, [&#39;uses&#39; =&gt; &#39;Auth\AuthController@postLogin&#39;, &#39;as&#39; =&gt; &#39;login&#39;]);
    Route::get(&#39;auth/logout&#39;, [&#39;uses&#39; =&gt; &#39;Auth\AuthController@getLogout&#39;, &#39;as&#39; =&gt; &#39;logout&#39;]);
    
    // Registration routes
    Route::get(&#39;auth/register&#39;, [&#39;uses&#39; =&gt; &#39;Auth\AuthController@getRegister&#39;, &#39;as&#39; =&gt; &#39;register&#39;]);
    Route::post(&#39;auth/register&#39;, [&#39;uses&#39; =&gt; &#39;Auth\AuthController@postRegister&#39;, &#39;as&#39; =&gt; &#39;login&#39;]);

I don&#39;t have much experience with Laravel, so please excuse my ignorance. I&#39;m aware that there is [another question][1] asking this same thing, but neither of the answers seem to work for me. Thanks for reading!


**Edit:**

Here&#39;s my register.blade.php as requested.

    @extends(&#39;partials.main&#39;)
    
    @section(&#39;title&#39;, &#39;Test | Register&#39;)
    
    @section(&#39;content&#39;)
        &lt;form method=&quot;POST&quot; action=&quot;/auth/register&quot;&gt;
            {!! csrf_field() !!}
            &lt;div class=&quot;ui input&quot;&gt;
              &lt;input type=&quot;text&quot; name=&quot;name&quot; value=&quot;{{ old(&#39;name&#39;) }}&quot; placeholder=&quot;Username&quot;&gt;
            &lt;/div&gt;
            &lt;div class=&quot;ui input&quot;&gt;
              &lt;input type=&quot;email&quot; name=&quot;email&quot; value=&quot;{{ old(&#39;email&#39;) }}&quot; placeholder=&quot;Email&quot;&gt;
            &lt;/div&gt;
            &lt;div class=&quot;ui input&quot;&gt;
              &lt;input type=&quot;password&quot; name=&quot;password&quot; placeholder=&quot;Password&quot;&gt;
            &lt;/div&gt;
            &lt;div class=&quot;ui input&quot;&gt;
              &lt;input type=&quot;password&quot; name=&quot;password_confirmation&quot;placeholder=&quot;Confirm Password&quot;&gt;
            &lt;/div&gt;
            &lt;div&gt;
                &lt;button class=&quot;ui primary button&quot; type=&quot;submit&quot;&gt;Register&lt;/button&gt;
            &lt;/div&gt;
        &lt;/form&gt;
    @endsection

  [1]: https://stackoverflow.com/questions/33517763/laravel-session-store-not-set-on-request

Laravel - Session store not set on request

Bob uses a web application in order to achieve something. And:

 - His browser is on diet, therefore it does not support **cookies**. 
 - The web application is a popular one, it deals with a lot of users at a given moment - it has to *scale* well. As long as keeping session would impose **a limit to the number of simultaneous connections**, and, of course, will bring a non-negligible **performance penalty**, we might like to have a session-less system :)

**Some important notes:** 

- we do have **transport security** (*HTTPS* and its best friends);
- behind the curtains, the web application delegates a lot of operations to **external services**, on current **user&#39;s behalf** (those systems do recognize Bob as one of their users) - this means that **we have to forward them Bob&#39;s credentials**.

Now, how do we authenticate Bob (on each and every request)?
Which would be a reasonable way to implement such a thing?

- playing *tennis* with the credentials via **HTML form hidden fields**... the *ball* contains the credentials (**username &amp; password**) and the *two rackets* are the browser and the web application respectively. In other words, we may transport data back and forth via form fields instead of via cookies. At each web request, the browser posts the credentials. Though, in the case of a **single-page application**, this may look like playing *squash* against a rubber wall, instead of playing *tennis*, as the *web form* containing the credentials might be kept alive the entire lifetime of the *web page* (and the server will be configured not to offer the credentials back).
- storing the username &amp; the password in the context of the page - JavaScript variables etc. Single-page required here, IMHO.
- encrypted token - based authentication. In this case, the log-in action would result in the generation of an encrypted security token (username + password + something else). This token would be served back to the client and the upcoming requests will be accompanied by the token. Does this make sense? We already have HTTPS...
- others...
- last resort: do not do this, store credentials in the session! Session is good. With or without cookies.

Does any web / security concern come into your mind, regarding any of the previously described ideas? For example,

 - *time-outing* - we may keep a **timestamp**, along with the credentials (time-stamp = the time Bob entered his credentials). E.g. when **NOW - timestamp &gt; threshold**, we might deny the request.
 - *Cross-site scripting* protection - should not be different in any way, right?

Thank you a lot for taking the time to reading this :)

How to do stateless (session-less) &amp; cookie-less authentication?

I know that a cookie with `secure` flag won&#39;t be sent via an unencrypted connection. I wonder how this works in-depth.

Who is responsible for determining whether the cookie will be sent or not?

How does cookie &quot;Secure&quot; flag work?

In my website when the user clicks on the &quot;Logout&quot; button, the Logout.aspx page loads with code `Session.Clear()`.

In ASP.NET/C#, does this clear all cookies? Or is there any other code that needs to be added to remove all of the cookies of my website?

How to delete cookies on an ASP.NET website

From the [php.net][1] documentation:

&gt; **[session_destroy][2]** — Destroys all data registered to a session
 
&gt; **[session_unset][3]** — Free all session variables

My three part question is:

The two functions seem very similar.  
What is really the difference between the two?

Both seem to delete all variables registered to a session. Does any of them actually destroy the session itself? If not, how do you accomplish this (destroy the session itself).

Is it correct that neither of the two functions deletes the session cookie at the client?


  [1]: http://php.net
  [2]: http://php.net/manual/en/function.session-destroy.php
  [3]: http://php.net/manual/en/function.session-unset.php

What is the difference between session_unset() and session_destroy() in PHP?

I am working on a page that requires javascript and sessions. I already have code to warn the user if javascript is disabled. Now, I want to handle the case where cookies are disabled, as the session id is stored in cookies.

I have thought of just a couple ideas:

 1. Embedding the session id in the links and forms
 2. Warn the user they must enable cookies if they are disabled (would need help detecting if cookies are disabled)

What is the best way to approach this? Thanks

**EDIT**

Based on the articles linked, I came up with my own approach and thought I would share, somebody else might be able to use it, maybe I will get a few critiques. (Assumes your PHP session stores in a cookie named `PHPSESSID`)

    &lt;div id=&quot;form&quot; style=&quot;display:none&quot;&gt;Content goes here&lt;/div&gt;
    &lt;noscript&gt;Sorry, but Javascript is required&lt;/noscript&gt;
    &lt;script type=&quot;text/javascript&quot;&gt;&lt;!--
    if(document.cookie.indexOf(&#39;PHPSESSID&#39;)!=-1)
       document.getElementById(&#39;form&#39;).style.display=&#39;&#39;;
    else
       document.write(&#39;&lt;p&gt;Sorry, but cookies must be enabled&lt;/p&gt;&#39;);
    --&gt;&lt;/script&gt;

Check if cookies are enabled

I have set the .ASPXAUTH cookie to be https only but I am not sure how to effectively do the same with the ASP.NET_SessionId.

The entire site uses HTTPS so there is no need for the cookie to work with both http and https.

How to secure the ASP.NET_SessionId cookie?

1. We want to store User&#39;s Authorization information in cookie which should not be lost upon refresh (F5) of browser.

2. We want to store authorization info in &quot;permanent-cookie&quot; in case user has opted for &quot;Remember Me&quot; check box at the time of log-on.


How to set expiration date for cookie in AngularJS

What is the distinction between **Sessions** and **Cookies** in PHP?

What is the difference between Sessions and Cookies in PHP?

I am working in an app where I need to keep some data during the user is logged in and I have that question, what is the difference among 
localStorage, sessionStorage, cookies ???

I was asking what can I use in order to persist some data in the DOM, even if the user refresh the page, some people says: use sessionStorage, or localStorage, then, someone came up with the idea of use [ngCookies](https://docs.angularjs.org/api/ngCookies/service/$cookies) because it works in every browser, but, which should I use ?

localStorage vs sessionStorage vs cookies

I&#39;m a bit confused as to how cookies work with Scrapy, and how you manage those cookies.

This is basically a simplified version of what I&#39;m trying to do:
![enter image description here][1]


----------


The way the website works:
--------------------------

When you visit the website you get a session cookie.

When you make a search, the website remembers what you searched for, so when you do something like going to the next page of results, it knows the search it is dealing with.


----------


My script:
----------

My spider has a start url of searchpage_url

The searchpage is requested by `parse()` and the search form response gets passed to `search_generator()`

`search_generator()` then `yield`s lots of search requests using `FormRequest` and the search form response.

Each of those FormRequests, and subsequent child requests need to have it&#39;s own session, so needs to have it&#39;s own individual cookiejar and it&#39;s own session cookie.


----------


I&#39;ve seen the section of the docs that talks about a meta option that stops cookies from being merged. What does that actually mean? Does it mean the spider that makes the request will have its own cookiejar for the rest of its life?

If the cookies are then on a per Spider level, then how does it work when multiple spiders are spawned? Is it possible to make only the first request generator spawn new spiders and make sure that from then on only that spider deals with future requests?

I assume I have to disable multiple concurrent requests.. otherwise one spider would be making multiple searches under the same session cookie, and future requests will only relate to the most recent search made?

I&#39;m confused, any clarification would be greatly received!


----------


EDIT:
-----

Another options I&#39;ve just thought of is managing the session cookie completely manually, and passing it from one request to the other.

I suppose that would mean disabling cookies.. and then grabbing the session cookie from the search response, and passing it along to each subsequent request.

Is this what you should do in this situation?

  [1]: http://i.stack.imgur.com/nn517.png

Scrapy - how to manage cookies/sessions

The documentation of `ActionDispatch::Cookies` gives nearly identical descriptions for both signed cookies and encrypted cookies. It appears that both use `secrets.secret_key_base` to prevent client-side tampering. http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html

## Signed Cookies
&gt; Sets a signed cookie, which prevents users from tampering with its value.
&gt; The cookie is signed by your app&#39;s `secrets.secret_key_base` value.
&gt; It can be read using the signed method `cookies.signed[:name]`

    cookies.signed[:user_id] = current_user.id

## Encrypted cookies
&gt; Sets an encrypted cookie value before sending it to the client which
&gt; prevent users from reading and tampering with its value.
&gt; The cookie is signed by your app&#39;s `secrets.secret_key_base` value.
&gt; It can be read using the encrypted method `cookies.encrypted[:name]`

    cookies.encrypted[:discount] = 45

------

My question is: What is the difference between the two?

When would you want to use one over the other?

What is the difference between signed and encrypted cookies in Rails?

I have a question regarding URLs:

I&#39;ve read the [RFC 3986][1] and still have a question about one URL:

&gt; If a URI contains an authority component, then the path component   
&gt; must either be empty or begin with a slash (&quot;/&quot;) character.  If a URI 
&gt; does not contain an authority component, then the path cannot begin   
&gt; with two slash characters (&quot;//&quot;).  In addition, a URI reference   
&gt; (Section 4.1) may be a relative-path reference, in which case the   
&gt; first path segment cannot contain a colon (&quot;:&quot;) character.  The ABNF  
&gt; requires five separate rules to disambiguate these cases, only one of 
&gt; which will match the path substring within a given URI reference.  We 
&gt; use the generic term &quot;path component&quot; to describe the URI substring   
&gt; matched by the parser to one of these rules.

I know, that `//server.com:80/path/info` is valid (it is a schema relative URL)

I also know that `http://server.com:80/path//info` is valid.

But I am not sure whether the following one is valid:

    http://server.com:80//path/info

The problem behind my question is, that a cookie is not sent to `http://server.com:80//path/info`, when created by the URI `http://server.com:80/path/info` with restriction to `/path`





  [1]: http://www.ietf.org/rfc/rfc3986.txt

Is a URL with // in the path-section valid?

When using sessions, Flask requires a secret key. In every example I&#39;ve seen, the secret key is somehow generated and then stored either in source code or in configuration file.

What is the reason to store it permanently? Why not simply generate it when the application starts?

    app.secret_key = os.urandom(50)

Why not generate the secret key every time Flask starts?

We have a simple performance test flow in an application.
 
 1. We login
 2. Search based on some criteria
 3. repeat searches for different parameters. 

We are using Jmeter to do a performance testing. We need to have multiple threads running to test this in a scalable manner.

The way we currently have this arranged is:

    -Test Plan
      - Thread Group
          - Cookie Manager
          - Login To application
          - Search on param 1
          - Search on param 2
      - results summary table
      - Summary report

So basically we have summary return table and report present on plan level while cookie manager is present on thread group level. 

When I run for one thread it runs fine and completes well. When I scale it to multiple threads, as soon as the next thread kicks off, the session for the last thread is invalidated. This causes failures for all the already running threads due to newly spawned thread.

I reached this result with observation:
&lt;br&gt;1. If I run multiple threads, only last thread has got valid responses in result summary tree
&lt;br&gt;2. If I run with 2 threads with ramp up period as 10 seconds, which means each thread gets time to finish itself, then both of them run successfully. 

As per my understanding each thread login&#39;s into application and since cookie manager is at thread level, the values will be maintained for session id for each thread respectively? But what is causing the override of the session id value between threads?

Any help will be much appreciated. 




All Session Cookies Solutions on Gang of Coders

Total of 20 Session Cookies Solutions