Skip to content
This repository was archived by the owner on Mar 22, 2022. It is now read-only.
This repository was archived by the owner on Mar 22, 2022. It is now read-only.

Feature Request: Anonymous Authentication Strategy Support #423

Closed

Description

@subodhpareek18

Many systems require an additional anonymous authentication strategy (over and above the existing local, jwt) for fresh customers landing on the website.

It might seem oxymoronic to authorize someone anonymously, but it makes a lot more sense to not freely open multiple endpoints and resources a user might need to touch and only provide a single entry point from where one can auth anonymously and then use the provided token (which could have things like session expiry, etc) to further deal with the system.

According to my explorations here: #411 currently this works out of the box for a rest client, but not for an io client.

A sub-request is to document this feature along with an example that has two auth strategies being used simultaneously, anonymous for fresh customers and local for internal team members.

Activity

  1. daffl commented on Feb 25, 2017

    @daffl
    Member

    The latest v1.0.0 allows to create anonymous JWT by default. Upgrading to v1.0.0 will allow the functionality you seem to be looking for.

  2. mmucklo commented on Mar 21, 2017

    @mmucklo

    @daffl I've read through #411 which leads over to this issue.

    I'm confused. At the end of #411 @ekryski suggests opening a new issue for anonymous authentication support.

    This issue is immediately opened and then closed quickly - 4 days later. Is that because the feature (anonymous authentication) was implemented or did you know something that @ekryski didn't?

  3. daffl commented on Mar 21, 2017

    @daffl
    Member

    As I said, v1.x of feathers-authentication allows to create anonymous JWTs (as @ekryski said in #411) out of the box. Just add a before create hook to /authentication that sets hook.data.payload to what you need in the JWT payload.

  4. mmucklo commented on Mar 21, 2017

    @mmucklo

    Ok, thanks for the quick response! I'm going to continue to give things a shot.

  5. mmucklo commented on Mar 21, 2017

    @mmucklo

    So I'm presently seeing the same issues as the poster in #411 - anonymous authentication works in REST, but fails in Socket.IO even if you're using a completely separate service.

    Here's the output of the frames I'm seeing in the web socket debug tab in chrome:

    screen shot 2017-03-21 at 12 49 02 am

    What it looks like is that the server is first responding with a NotAuthenticated error, then it tries to return the actual token however the client is only seeing the Error message, and the "catch" section of the Promise is being called.

    Code I'm using to authenticate - see the remove function below (Angular2 frontend, so this is Typescript):

    @Injectable()
    export class CrawlService {
        private _socket;
        private _rest;
        private _restApp;
        private _socketApp;
    
        constructor(
            private _socketService: SocketService,
            private _restService: RestService
        ) {
            this._rest = _restService.getService('crawls');
            this._socket = _socketService.getService('crawls');
            this._socketApp = _socketService.getApp();
            this._restApp = _restService.getApp();
        }
    
       /// ....
    
        remove(id: number, query: any) {
            console.log(this._socketApp);
            (<any> window)._socketApp = this._socketApp;
            return this._socketApp.authenticate({
                strategy: 'jwt'
            }).then(
                res => {
                    console.log("authenticated - socket", res);
                    (<any> window)._socketRes = res;
                    this._socket.remove(id, query);
                }
            ).catch(
                error => {
                    console.log("authentication error", error);
                }
            );
        }
    }

    this._socketApp is set to the feathers() client (which has had authentication setup as follows)

    @Injectable()
    export class SocketService {
        public socket: SocketIOClient.Socket;
        private _app: any;
        private _base_url: string;
    
        constructor() {
            this.socket = io(HOST);
            this._app = feathers()
                .configure(socketio(this.socket))
                .configure(hooks())
                .configure(auth({
                    storage: window.localStorage
                }));
        }
        getApp() {
            return this._app;
        }
        getService(name) {
            return this._app.service(name);
        }
    }

    Here's what shows up in the client:

    screen shot 2017-03-21 at 12 49 51 am

  6. mmucklo commented on Mar 21, 2017

    @mmucklo

    Update:

    After combing around documentation on the web and reading about socket-jwt, I tried a different approach that seems to work.

    1. Authenticate first with REST
    2. (automatic: store token in localStorage)
    3. Authenticate using stored token on socket.io
    4. Then process socket.io request.
            return this._socketApp.authenticate({
                token: window.localStorage.getItem('feathers-jwt')
            }).then(
                res => {
                    console.log("authenticated - socket", res);
                    (<any> window)._socketRes = res;
                    this._socket.remove(id, query);
                }
            ).catch(
                error => {
                    console.log("authentication error", error);
                }
            );
  7. daffl commented on Mar 21, 2017

    @daffl
    Member

    On thing you can do to get everything via socket.io is calling app.service('authentication').create().then(jwt) on the client and then authenticating with the jwt strategy using the token you get back.

    I think the problem is that the Socket authentication tries to use a passport strategy. Maybe the fallback should be to call authentication.create instead of throwing an error. Would you mind creating an issue for this?

  8. ekryski commented on Mar 22, 2017

    @ekryski
    Member

    It might actually be related to the same thing that @marshallswain created #455 for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions