What are all the steps needed to config WildDuck'a API to use X-Access-Token?

[true2thepen]

What are all the steps needed to config WildDuck'a API to use X-Access-Token?

[louis-lau]

If you just want a "root" token with all permissions, you just simply set it here:

wildduck/config/api.toml

Line 11 in a15878c

#accessToken="somesecretvalue"

[true2thepen]

Thanks; but that is the accessToken, not X-Access-Token header. That you have to tack on to the url ?accessToken=somesecretvalue. In the api when you authenticate you can request token for X-Access-Token use. The question is how to you setup the api to use X-Access-Token, not accessToken.

[louis-lau]

It doesn't matter. You can put it either in the url or in the header. Both should work.

[true2thepen]

Authenticate via api with username/password and token set to true. This returns a token you use in X-Access-Token. Yet it doesn't matter if you send it or not. Setting accessToken in api.toml sets a single token not individual user token for X-Access-Token header.

[louis-lau]

Setting the token in api.toml sets the root token that can do everything. Getting a token from /authenticate will get a token that has scoped permission to the user. It won't be able to access the DKIM endpoints for example.

There is no difference between accessToken and X-Access-Token. There is a difference in permission depending on the token you use.

[true2thepen]

The difference in permission is why I don't want to use accessToken. When the user logs into the system getting a token scoped for the user's use is what I want. Not blanket token. X-Access-Token isn't working. with accessToken turned on if you don't pass it on the url it doesn't work.

[louis-lau]

Works fine for me:

wildduck-access-token-flow.mp4

[true2thepen]

It's not working here. That's why I asked for exact steps to set it up. Setting accessControl.enabled to true and leaving accessToken commented out - not working. Put something in for accessToken and put it on url works; put it in X-Access-Token doesn't. Individual tokens don't work period.

[louis-lau]

This is the logic:

wildduck/api.js

Lines 226 to 230 in a15878c

	let accessToken =
	req.query.accessToken ||
	req.headers['x-access-token'] ||
	(req.headers.authorization ? req.headers.authorization.replace(/^Bearer\s+/i, '').trim() : false) ||
	false;

Have you made sure the query parameter isn't set when using the header? If you're using a proxy, have you made sure it's not stripping the header? I can't reproduce it "not working" locally. If none of these are the case, can you elaborate more on what requests you are sending and what responses you are getting?

[louis-lau]

btw, youc an also generate role access tokens with the access-tokens script without settings accessToken in the config, see te docs:
https://docs.wildduck.email/#/in-depth/roles?id=roles

[true2thepen]

Yes. The query parameter is not set. And yes I looked through the code.
First authenticate to get token.
Using the users endpoint without accessToken set and setting/not setting X-Access-Token I get
{
"code": "InvalidToken",
"message": "Invalid accessToken value"
}

The endpoint doesn't matter as I have tested several and get the same response.
I don't want role tokens, I want user tokens. That's the whole point of being able to get user tokens is to use them. Setting accessControl.enabled to true and not setting accessToken results in the same response. Setting accessControl.enabled to false, tokens are no longer used.
I've turned secure to true/false - no difference.

All I want are the exact steps to set Wildduck api to use X-Access-Tokens. Having that I can go through and see if/where the mistake lies. Just because you can't replicate what I am seeing right in front of my eyes, doesn't mean something isn't wrong. Which is why I keep asking for the exact steps to set it up. I'm not asking for you to diagnosis what is wrong, I want the steps to go through so, I can do it.

This conversation could have been immensely shorter had the steps to set it up been given first. So far, you have only alienated me away from this project. I mean, how hard is it to list the steps to set it up?

[louis-lau]

All I want are the exact steps to set Wildduck api to use X-Access-Tokens
how hard is it to list the steps to set it up?

1. set accessControl.enabled to true
2. call /authenticate to get token
3. use token in X-Access-Token header

There you go. Can you see how that would not have been helpful to your situation at all?

I have no crystal ball to see why this doesn't work for you. I'm a real human, trying to help you debug why your setup is not working for free (within 10 minutes of you posting your question). I can see you're frustrated because things don't work, but getting angry at the person that is voluntarily giving their time to answer your questions is quite rude.

I can see you're not happy with me volunteering my time to help you. That's alright, from now on I won't. Perhaps someone else can help you instead. Have a nice day!

[true2thepen]

Had you give the steps to start with things would have been different. One, you didn't answer the question you rabbited on to setting up 'root' permission. Which wasn't what I asked. Next, you simply said it should work either way. Still no steps given. And on. The above doesn't work as unless accessToken is set and passed via the url it returns the previous mentioned error. Trying to debug would have gone a lot easier and quicker had you listed the steps first. I do appreciate the time; but, you failed to answer a simple question to start off with and only answered it on your seventh reply. So, don't cry about being human, we all are. Angry at you, nope. Just disappointed in that a simple question took 7 replies to get a straight answer. Don't try to set your bad move onto someone else. Simple question asked only required a simple answer that took --- SEVEN replies. You have a good day. @andris9 you have a great project; but, seriously why are simple questions so hard to answer?

[louis-lau]

Your initial question was about passing the token in the X-Access-Token header. You can pass the root token there, that header has nothing to do with whether it's a user token or not. This is where that answer came from. When you asked about passing it as a query parameter or a header, I answered that it doesn't matter, because they should be interchangeable.

Perhaps I am flawed in answering questions, that's very possible. It's also possible the question was unclear, and needed some back and forth to clear up. I only said I was human because the way you're treating my answers is like you would treat ChatGPT or a servant.

Good to hear you're not angry. Sad you're disappointed, but I also feel like I've done my best to help you. You still remain rude, but I guess that's by choice :)

[true2thepen]

Big fat title: What are all the steps needed to config WildDuck'a API to use X-Access-Token?

Rude is not answering the question. I asked my question in the title and then elaborated a bit. All you had to do was answer. You did on your seventh reply. The frustration came because I asked a very simple question and it took pulling teeth to get it. Your answers were not answering my question. Can you see how that would frustrate someone? If the question was unclear ask for clarity. I was not ever rude to you. If you felt that way, sorry.

[louis-lau]

The answer to that title is that you can set the root token and use it in that header. That is the simplest way to set up any form of header auth with wildduck. It was never clear you wanted to use role based auth for specific users. I could have asked for clarification, but I had no reason to. I was answering the question I thought I had been given. The question may have looked simple to you, but perhaps it's easy to interpret it in a different way.

I'm glad you didn't mean to be rude, but I hope you can see that you came across that way with the things you said. I personally don't see how trying to answer a question but not immediately succeeding is rude. I can see how it's frustrating, but especially with free open source, patience for support is a price you pay. It's not nice to expect otherwise.

I accept your apology. Sorry if I frustrated you, it was very much not on purpose. I have a splitting headache and am going to lay on the couch for a bit. Perhaps I or Andris can figure out what's going wrong later.

[true2thepen]

Louis, what version are you using? OS? This is what I did and I'm still getting the same results. You either use a single token via accessToken in the url query with accessControl.enabled set to true or no tokens at all. Any other combination results in invalid token.

Ok. Redid VPS. Ubuntu 22.04. Used install script.
Did step 1 from above: Changed accessControl.enabled to true. Restart wildduck.
Did step 2 from above: Result of authenticate via api is Invalid token.
Only way to authenticate is to set accessToken and pass via query param. Any other combination results in Invalid Token.

Even did the above with rebooting between steps 1 and 2 and get same results.

If you set accessToken, it negates the use of X-Access-Token and makes individual tokens useless as you can't pass them without sending the accessToken (set in api.toml) via query param. Not sending accessToken via query param and using X-Access-Token header to send results in invalid token response as well.

This is from a fresh install of everything.
Starting up Haraka version 3.0.2
info App ---------------------- [email protected] ----------------------
info App ------------------------ [email protected] -----------------------

With the Release being 1.41.3 as of Dec 19, not sure why wildduck is reporting it's version as 1.39.14, unless the release and version number of wildduck aren't related.

Not sure what else to try now. Suggestions are welcomed.

[andris9]

accessToken and X-Access-Token are exactly the same thing. You can use one of these but not both.

1. Create a token for the role "tokenAuth" using the access-tokens utility (see here)
2. Run API request /authenticate (See here) with the tokenAuth token set either for accessToken query argument or X-Access-Token header. Set token property in the payload to true
3. API request returns you a temporary token for the authenticated user (assuming that username and password were correct)
4. Use the returned temporary token either for the accessToken query argument or X-Access-Token header (doesn't matter, it's the same). You can make API requests only for the authenticated user.