-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Anonymous #240
Comments
The username/password are to avoid having anonymous/anonymous as an attack vector. So maybe simpler and safer to have: So you HAVE to provide values, and have only one flag to configure. |
How are the credentials being passed in the client id for checking? If we allowed anonymous users but don't correctly define the client id checking for this case, then we might effectively allow access to resources that might not be supposed to be accesible. But maybe I'm missing something, so if you can provide a full fledged example I can take a look into it. |
The client ID has the credentials, for instance, copied from link, Object Key with suffix example: OAuth Token with suffix example: bearer:BzlLgdFpfj2ChLSBsZmgyK46tV1cA0bK:my-client-104df In effect, the apikey/bearer is the password and the "my-client" part is the user name. the username/password is ignored, and in this case, not sent. The device lacks ability to set these to dummy values. Question is -- is it a generally useful thing for other users, or an edge case? I could modify and build my own version, passing "null" for username and password (as long as clientId is not null), and let my authenticator take care of it. In general case null/null will not be valid username and password and will be rejected. I picked "anoynmous" before base on mosquitto flag, but "null" is more descriptive. |
Thanks for the explanation, I think I get the case better now: if we allow anonymous users, we'll set their username and password to fixed ones provided by the conf options. Then you'll use some backend that allows you to forward the Is my understanding correct? |
Yes I think you get it. If an authenticator wants to use ClientID to embed username/password, allow username and password to be null. And do it the simplest way possible. It didn't occur to me, but can you just pass NULL down the stack and let the authenticator deal with it? and will MQTT's flag "allow_anonymous false" provide the same filter anyway? So only if someone sets "allow_anonymous true" will NULL for username and password even get to the plugin. I am thinking I can build this and try it first. And my need is transitory (will be fixed in eventual firmware update) so if it doesn't fit in the spirit of the project, I get it. |
Iḿ sorry, I absolutely lost track of this issue. Is this something that's still worth pursuing, @WilliamBradee? |
Cool, thanks for your response. |
As a integrator of legacy application I want to use go-auth with blank username and password so that I can support passing credentials in the Client ID.
In a legacy application the authentication information is carried in the client ID and username/password are blank.
MQTT does allow authentication without username/password.
Mosquitto config already has flag "allow_anonymous"
Proposal:
add flags :
Change code at https://github.com/iegomez/mosquitto-go-auth/blob/5dc063f1041b94dd67ededf47f79fa58b0968c68/auth-plugin.c line 90
if (username == NULL || password == NULL) {
printf("error: received null username or password for unpwd check\n");
fflush(stdout);
return MOSQ_ERR_AUTH;
}
Consider the config. If auth_opt_allow_anonymous is true and auth_opt_anonymous_username/password are set, replace NULL username and password with auth_opt_anonymous_username/password. If auth_opt_anonymous_username/password are not set, replace NULL username and password with "anonymous". If auth_opt_allow_anonymous is not set or is false, keep current behavior.
The text was updated successfully, but these errors were encountered: