Auth via env broken?

[vuaru]

I've been trying to use this as specified in the readme, ie. storing the auth details in the environment like:

STORMPATH_CLIENT_APIKEY_ID=xxx
STORMPATH_CLIENT_APIKEY_SECRET=yyy
STORMPATH_APPLICATION_HREF=https://api.stormpath.com/v1/applications/xxx

But I get:

ResourceError: HTTP 401, Stormpath 401 (http://www.stormpath.com/docs/quickstart/connect): Authentication with a valid API Key is required.

However, when I (finally) noticed that the following way was supported as well, i tried it out (with the same auth details) and it worked instantly:

stormpath.init(app, {
  client: {
    apiKey: {
      id: 'xxx',
      secret: 'yyy'
    }
  },
  application: {
    href: 'https://api.stormpath.com/v1/applications/xxx'
  }
});

[robertjd]

Can you confirm which version of this library you are using? I'd also check the following before you run the server:

• Ensure that the variables were exported, using the env command to list your current environment variables
• Ensure that the API Key and Secret are still valid and haven't been disabled or deleted. You can do this by logging into the Stormpath Admin Console and clicking "My Api Keys" from the drop-down menu in the upper right

[vuaru]

npm ls
├─┬ express-stormpath@2.0.10

I printed them out during debugging via console.log, and they were present. Also, I believe it throws a different error when they aren't.

The API key and secret are still valid:

• Listed on the site
• The other method mentioned above
• Via curl
• Via .stormpath/apiKey.properties using the base stormpath package.

[robertjd]

Could you try deleting the .stormpath/apiKey.properties file? I wonder if there is a conflict when that file and the environment variables exist.

[vuaru]

No change.

[erbridge]

I am using the environment variables fine with 2.0.10. I also have a local apiKey.properties file in the project root (which stopped working for me in an earlier 2.0.x).

[robertjd]

Thanks for the update. I'm still trying to find a way to reproduce this problem. Could you share your entire package tree as a gist? I want to ensure that we don't have any rouge stormpath dependencies that are getting inadvertently required.

[typerandom]

I think this has to do with the new way that configuration is being loaded. I'll look into this right away. According to the error an API key is being provided somewhere, but when used, authentication fails.

This is currently the order in which API keys are being loaded. Notice that as keys are being loaded, they overwrite any previously loaded keys.

1. Environment
2. ~/.stormpath/apiKeys.properties
3. ~/.stormpath/stormpath.json
4. (application path)/apiKeys.properties
5. (application path)/stormpath.json
6. Config provided to integration (i.e. stormpath.init(app, { /* here */ });).

So it sounds as if you have some other file along the way that are overwriting the keys that you have in your environment. Can you check that you don't have any of the files as in the list above (step 2-5)?

[erbridge]

it seems strange to me that the environment is the bottom of the heap. I would have expected it to override all the files (except 6).

[robertjd]

I agree with @erbridge , I think that the environment variables should override everything except 6

[typerandom]

@erbridge @robertjd I agree with you both. That actually makes more sense. I think we need to put this down on spec so that all SDKs have the same behaviour. Looking at the C# SDK we're also doing loading of API keys there a bit differently.

https://github.com/stormpath/stormpath-sdk-csharp/blob/f6b72c2aa589f0505151dd8d2475cddeb3b6b9fd/Stormpath.SDK/Stormpath.SDK/Impl/Api/DefaultClientApiKeyBuilder.cs#L119

@rdegges What do you think?

[typerandom]

Just waiting for a new SDK version then we'll be able to close this.

[typerandom]

Closing issue since it should have been resolved around 15th of October.