The URL should be something like http://localhost:5678/api/v1 that is what I am using on my install, Just to check you are using the API key from Settings > API right?
Are you using basic auth as well as that can cause issues as it adds an extra authentication layer to it that isn’t really needed if you are using the User Management feature.
Also having this same issue and also trying to understand the need or not of the User Management Feature which has now somehow appeared after update.
I thought the user management feature was a paid feature, and that is why we have not so far considered it. If that is an alternative to http basic auth with a single user we could consider it and then also resolve the api access as I understand.
User Management is not a paid feature and basic auth can still be used. The page may appear if you have not disabled the feature but it would have been there for a while, The first thing you would see once enabled is the system asking you to create an owner account.
If someone has gone through and created it and you are not aware of them doing it things will be a bit trickier.
Hi again. As far as I understand, the User Management does not have a “true” flag unless it is there by default. We have no related option on it. Maybe someone setted the email and user account on the UI but never registered a password or activated anything.
As I am still logged in from my last (http) login I do see on the UI now under users option.
I am not sure now if I should create the default account now or not and if that makes it mandatory to maintain it, configure smtp, etc
Back to the API access with http enabled I tried your suggestion of doing a previous http login to the api with the basic auth credentials for n8n but that also returns an error.
If I do it to http://localhost:5678
ERROR: Authorization failed - please check your credentials
I have double-checked the credentials and believe they are ok.
Not sure if this might be related to the User Management feature becoming activated suddenly.
Are you using the api url as well? Just setting the domain won’t work it needs the full path so it would be what I put earlier along with the endpoint to get all workflows.
You will then need to set the header value for the api key and add in basic auth to match your environment.
The config key is N8N_USER_MANAGEMENT_DISABLED the default value is false so if you don’t want user management you would need to set it to true.
If you create an owner account it will be tricky to disable it so I would set the env option and restart the container.
Is it any way to determine if the “user account” was created or not?
I have now included the env value to disable the USER_MANAGEMENT to true, but still the same.
The most odd thing is that if I login from my normal Chrome profile it works fine but if I use an incognito window I get the http login and then the n8n login so I have the impression something is not working as expected.
No big deal if I have to end up configuring the user_management as I understand is your recommended config but I am concern at the moment that I end up “loosing” access as I do not currently have default user password configured. If I setup the default user I get that message saying that if I will need to share all the workflows and credentials with the other users and I understand that is a cloud/paid feature, therefore my concern.
On the other hand regarding the api access in case I remain with basic_auth I am not sure I understand. I’ve tried the http login on a node pre-api node as on the previous image. Used the same path for the http login credentials and api node but get a “page not found” on the first one.
I am not sure if you mean that I would need to add the api token as a header on the http node.
You could query the database to see if the account has been made but it does sound like something really odd is happening with your setup. The page is saying you can set up your owner account so you shouldn’t see a login page, did you ever use user management then disable it?
If you did create the owner account now it will set all of your current workflows to be owned by that account, if you then added more users to the system that would also be free but if you wanted to share credentials and workflows between the users that would then require a license.
To get the API request working you need to set the api key header as mentioned in our api docs, this would be a header value that needs to be added. The complexity here is because basic auth needs to authenticate before it can load the page then the normal auth can happen.
No. Perhaps a colleague introduced the email address to the default user while N8N_USER_MANAGEMENT_DISABLED was still not set, but never “registered” a default account or introduced a password. As you say, if I remove that setting flag I get offered to register the default account and if I set it I still get asked to login. Truly, at a certain point I saw a user icon bottom left corner which now has disappeared again. For your reference, this is the list of cookies I have on the Chrome profile that still “works” only with basic_auth password. The rest after auth_basic passed get the n8n login page.
I guess at this point I either roll-back to a backup or assume I’ll have to use the user_managemente feature. At least that would solve my API access problem I guess.
Nevertheless may I suggest that you document (or template workflow) how to access the API with basic_auth activated. I am still not 100% sure if our approach of a previous http request is what you meant or not.
I suspect there is an owner account on your system and that is why there is an n8n-auth header set unless it is coming from somewhere else, I just don’t know why there is no user showing up in the list but the user existing would explain why in incognito mode you get a prompt unless maybe the option was skipped in which case turning it off would do the job. What version did you upgrade from? I can test the process and see if I can reproduce the issue, If you can share the exact environment options you use with any important values removed I can set up a similar test to what you have.
Now I am at my computer it is easier to show you how you can use the API with Basic Auth… You would need to first set the URL to the one mentioned previously but also include the API call you want to make so to get workflows it would be something like http://your-url/api/v1/workflows
Then you would need so set your Basic auth credentials, for Authentication select Generic, Type > Basic and select your n8n credential.
Once this is done authenticating against the actual API will be needed so you would need to send a header with a name of X-N8N-API-KEY and the value you get from the API settings on your instance. The node would then look something like this…
I believe it was 214.2 to 216.1 and now at 217.2
We’ve always had the basic_auth activated and only yesterday after upgrade we configured the N8N_USER_MANAGEMENT_DISABLED to true as our installation was previous to that feature. As I mentioned, the issue could have been for assigning an email to the default user showing up in the bottom left corner. Nevertheless, if it’s doable I think it would makes sense that that flag removes the n8n loging options completely in any scenario. That is obviously a suggestion.
We still have to decide if we will rollback or assume to start using the user management from now on.
As for the API call with basic_auth I am afraid is still not working completely altough the http request seems to go through now, but the API call still returns
ERROR: Authorization failed - please check your credentials
But this might be due to our “odd” situation with the user management config. I’ll update if we roll back.
I suspect then by setting the email it has done it, I guess you wouldn’t need an email as normally you wouldn’t see the user option.
I am still very surprised that the page didn’t show before though as the default has been to show it since the feature was released or that is my understanding.
In theory with the http request that should do the job and the user management side shouldn’t cause anything to break on that it also looks like it has ran, I maybe should have been clearer… You won’t be able to use the n8n node which looks to be where the error is coming from so all of the n8n nodes would be replaced with the HTTP Request node.
Since access to the API is locked behind the API Key, I felt safe in setting this environment flag to disable BASIC_AUTH check at the n8n /api/ endpoint.
N8N_AUTH_EXCLUDE_ENDPOINTS=api
Of course, this is not going to be a viable solution for everyone.
