Problems with using superlogin on apps

[Shocoben]

What's the problem ?

I've some problems using superlogin while creating an app with nodewebkit

I've used superlogin-demo as a base.

But had to overwrite some parts like the logout in routers and the authorization on the profile refresh.

The main problem is that in superlogin, passeport's "bearer" and header.authorization on http request are often used to find the user's session. But it looks like if the server and the client aren't hosted on the same computer, it doesn't work.

Here are some "patch" that I used in my fork :

Commit 1
Commit 2

How to repeat the problem, without Nodewebkit ?

1. Clone superlogin-demo
2. Configure superlogin-demo server, and start it with npm start (like said in the Readme)
3. Copy the client part on an apache Server
4. Start the apache server, and access to the superlogin-demo Client by Apache.
5. Remove "<base href="/">" in index.html, and remove the use of $location in src/app.js and src/token/token.js (By passing the problem parts as comment)
6. In src/app.js, configure superloginConfig.baseUrl to set your nodejs server url (Like http://localhost:3000/auth/)
7. Sign-up and/or log-in
8. Try to** log out** and you should have also a 401 error on superlogin-demo Server

{ error: 'unauthorized', status: 401 }
POST /auth/logout 401

1. You'll have the same problem when you try to access to the user'sprofile. But to see the 401, you have to modify the url of the http.get in src/profile/profile.js and you should see 401 error on superlogin-demo Server. Url sample : http://localhost:3000/user/profile

If you try it in localhost on you computer, you should need to add cors to the nodejs server

I'll try to easily upload a .zip with the nodejs server and apache client ready, so it'll be more easy to setup.

I've also tried it with a distant server, to see if it's not the cors and localhost the problem but the same problem occurs.

So, is there a way to solve more easily my problems than my patches ?

[colinskow]

That is a strange issue. You should dig deep to figure out what is happening to the bearer header? Is it being suppressed by the client or by the server?

Meanwhile check out the source code for my bearer implementation. You can use the Authorization header or a bearer_token property in the body, or a bearer_token query parameter. But the query parameter is not secure since it is not encrypted even over an https connection. (You do not have to modify any SuperLogin source code to make this work.)

But since the Authorization header is the simplest and most secure way to make it work, it is worth researching why NodeWebkit is giving you problems. Try this solution and see if it helps.

[colinskow]

I believe this answer may solve your issue without modifying any SuperLogin code on client or server.

[colinskow]

The simplest solution is to disable web-security in NodeWebkit to remove cross origin limitations.

[Shocoben]

Ok, So I followed you advice and looked about the header.

I noticed that the authorization wasn't included. So I search about it in the client, and BOUM I found

    service.request = function(request) {
      var session = superloginSession.getSession();
      if(session && session.token) {
        superloginSession.checkRefresh();
      }
      if(checkEndpoint(request.url, endpoints)) {
        if(session && session.token) {
          request.headers.Authorization = 'Bearer ' + session.token + ':' + session.password;
        }
      }
      return request;
    }; 

What does it means ? It's just a problem of endpoints, and I didn't declared any endpoint in the config.

So, if you have the same problem as me, you simply have to configure your app like this :

var superloginConfig = {
      baseUrl: 'http://localhost:3000/auth/',
      endpoints: ["localhost:3000"], //Here
      checkExpired: 'stateChange',
      providers: ['facebook', 'google', 'github', 'windowslive', 'linkedin']
    };
    superloginProvider.configure(superloginConfig);

[mredbishop]

@colinskow The query string is absolutely encrypted over an SSL (https) connection. The server might be writing it to log files or something similar but the entire request including the query string, the whole URL, and the type of request like GET or POST is encrypted.