Closed gompa closed 4 months ago
Could you provide some more details which tools you are using? Using the same version, it works fine for me, full example below:
$ curl -X POST -d '{"password":"cJ/RH4Z1xKAu8Lk2DfRbhi6cZ3F4mG26AXhkZ8n4Ad0="}' 127.0.0.1/api/auth | jq
{
"session": {
"valid": true,
"totp": false,
"sid": "W1fiKShVr9YXHh91i1iUzA=",
"csrf": "mKijoLyeCEfL/SGL5YNUOw=",
"validity": 1800
},
"took": 0.09941768646240234
}
One additional hint: When requesting GET /auth/app
, you will be provided with an example of a password suiting our security standards. Nothing more than that. This GET
alone will not enable this password for you (it is idempotent)!
To enable the application password, you will have to use PATCH /config
(webserver.api.app_pwhash
) to the hash
provided to enable this new password, e.g. quoting from your post above
generate new app password using client token: result:
{"app":{"password":"PtqvT4mnl5lK/KnWNPY1Qnnlxq2W++fxDfP59BgRZeU=","hash":"$BALLOON-SHA256$v=1$s=1024,t=32$OFffzmu3Ys1/lghFoyw+Cg==$b24QQhKw3EWPNcOjLdMzofa2k3KjSTlwgZMCQs3pG/c="},"took":0.099813461303710938}
Let's apply the hash
you provided in your example:
$ curl -X PATCH -d '{"config":{"webserver":{"api":{"app_pwhash":"$BALLOON-SHA256$v=1$s=1024,t=32$OFffzmu3Ys1/lghFoyw+Cg==$b24QQhKw3EWPNcOjLdMzofa2k3KjSTlwgZMCQs3pG/c="}}}}' 127.0.0.1/api/config/webserver/api/app_pwhash | jq
{
"config": {
"webserver": {
"api": {
"app_pwhash": "$BALLOON-SHA256$v=1$s=1024,t=32$OFffzmu3Ys1/lghFoyw+Cg==$b24QQhKw3EWPNcOjLdMzofa2k3KjSTlwgZMCQs3pG/c="
}
}
},
"took": 2.574920654296875e-05
}
This enables your app password:
$ curl -X POST -d '{"password":"PtqvT4mnl5lK/KnWNPY1Qnnlxq2W++fxDfP59BgRZeU="}' 127.0.0.1/api/auth | jq
{
"session": {
"valid": true,
"totp": false,
"sid": "vrIufq7jpxL6CRXSyprT1g=",
"csrf": "PBehxmbTMpAFSVr1qTDPSA=",
"validity": 1800
},
"took": 0.13706016540527344
}
Thank you for the information, and you are right; I just requested the app password and never set it in the config. Setting it using the patch web API call works as expected.
However, when trying to set it by calling: pihole-FTL --config webserver.api.app_pwhash 'passwordhash'
, it's required to restart the FTL service for the new password to work.
Is this the expected behavior?
However, when trying to set it by calling:
pihole-FTL --config webserver.api.app_pwhash 'passwordhash'
, it's required to restart the FTL service for the new password to work. Is this the expected behavior?
No, it is not and there is actually no restart necessary on my local Pi-hole:
$ curl -X POST -d '{"password":"PtqvT4mnl5lK/KnWNPY1Qnnlxq2W++fxDfP59BgRZeU="}' 127.0.0.1/api/auth | jq
{
"session": {
"valid": false,
"totp": false,
"sid": null,
"validity": -1
},
"took": 0.1096031665802002
}
$ sudo pihole-FTL --config webserver.api.app_pwhash
$ sudo pihole-FTL --config webserver.api.app_pwhash '$BALLOON-SHA256$v=1$s=1024,t=32$OFffzmu3Ys1/lghFoyw+Cg==$b24QQhKw3EWPNcOjLdMzofa2k3KjSTlwgZMCQs3pG/c='
$BALLOON-SHA256$v=1$s=1024,t=32$OFffzmu3Ys1/lghFoyw+Cg==$b24QQhKw3EWPNcOjLdMzofa2k3KjSTlwgZMCQs3pG/c=
$ curl -X POST -d '{"password":"PtqvT4mnl5lK/KnWNPY1Qnnlxq2W++fxDfP59BgRZeU="}' 127.0.0.1/api/auth | jq
{
"session": {
"valid": true,
"totp": false,
"sid": "X7/zbDgyiN0QIFhR8mNG2A=",
"csrf": "8bOL9WIhLyoHh/79aNJCqg=",
"validity": 1800
},
"took": 0.1388406753540039
}
I assume your observation that a restart is required corresponds with the running FTL process not getting to know that the config has changed and, hence, that it needs to re-read the file. Do you see a line like INFO: Reloading config due to pihole.toml change
in your /var/log/pihole/FTL.log
when running the pihole-FTL --config ...
command?
I believe there might be a 'race condition' occurring on my end. If the login request is sent too quickly after changing the password with pihole-FTL --config, it may fail to authenticate.
Thank you for your assistance, and sorry for the noise.
No worries, maybe someone will arrive here via Google in the future and have the same question. Glad it's arrived for you!
I think we can improve the API documentation to be more explicit about that the app password needs to be applied before it can be used.
Versions
Pi-hole: Core Version is v5.17.3-282-gc771739f (Latest: null) Branch is development-v6 Hash is c771739f (Latest: c771739f)
AdminLTE: Web Version is v5.19-670-gda7c0efb (Latest: null) Branch is development-v6 Hash is da7c0efb (Latest: da7c0efb)
FTL: FTL Version is vDev-9e3ccd9 (Latest: null) Branch is development-v6 Hash is 9e3ccd91 (Latest: 9e3ccd91)
Platform
Expected behavior
to be authenticated with app password
Actual behavior / bug
always get the following response if using app password: {'session': {'valid': False, 'totp': False, 'sid': None, 'validity': -1}, 'took': 0.04996514320373535}
example :
Steps to reproduce
Steps to reproduce the behavior: