Issues using new token attribute in AdminAuth

I try to authenticate admins based on a header variable using new tokens feature of nodered 1.1.
Here some sample code in settings.js, but unforunately this does not work. It just displays the login dialog, without a field to type-in username/password or anything.
In the logs I can see, that "token" contains the header (email in my case)
Can you give me a hint, what I'm doing wrong?

    adminAuth: {
    tokens: function(token) {
        return new Promise(function(resolve, reject) {
            if ("" == token) {
                // Resolve with the user object. It must contain
                // properties 'username' and 'permissions'
                var user = { username: 'admin', permissions: '*' };
            } else {
                // Resolve with null as this user does not exist
1 Like

Hi @crackytsi

you've hit a bug - can you raise an issue on - we'll have a 1.1.1 release this week and should be able to get this fixed.

The token feature was primarily intended for automated admin api access where the editor is otherwise secured using an OAuth based strategy.

It looks like the use case of using it to authenticate access to the editor itself was not properly tested, even though it's a perfectly valid use.

Thanks for the fast response.
I created issue:

1 Like

@knolleary: I've updated Node node red to 1.1.1 but unfortunately it seems to be still not working as expected.
a) If I was already authenticated I see a NodeRed token (I guess the session token)
b) If I wasn't already authenticated I just see the login dialog without any input method.
Is there another issue? I still stick to the example code mentioned before.

Where do you see that?

In your adminAuth you have not defined the type of Auth, so the editor doesn't know what to present in the dialog. What would you expect to see given you don't want to use username/password Auth?

How are you giving your custom Auth token to the editor to use? I would expect you to be using the access_token query parameter when you first redirect the browser to the editor. Otherwise the editor has no idea what token you expect it to use.

My plan is to use a header variable as authentication token (in the header variable is the username). so I don't expect any dialog at all, as I defined a function to resolve this header variable to a user with permissions. Or is this a wrong expectation?

And how does the header variable get set?

I use a reverse proxy that requests a certificate authentication and sets the header variable according to that.
So when I print out the token, I can see the valid set token representing the email adress of the authenticated user.

Ok - so I can see this isn't going to work. The editor needs to know the token so it can be passed over the WebSocket comms link to authenticate it.

Not sure if there's a quick fix here - we don't currently do any header-based authentication of the websocket link.

I've reopened your issue -

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.