This will actually impact/break lnurl-auth for people using it right now, so we need to tell them beforehand, or even give them a button to migrate the account.
This will actually impact/break lnurl-auth for people using it right now, so we need to tell them beforehand, or even give them a button to migrate the account.
Do you know if there is a way that we can keep the user's credentials?
lndhub.go uses a different password hashing algorithm I think.
can we actually make people to actively migrate? then we probably could make sure the users keep the same credentials. And thus also the LNURL-auth keys would not change (when used in Alby and others)
Do you know if there is a way that we can keep the user's credentials?
lndhub.go uses a different password hashing algorithm I think.
can we actually make people to actively migrate? then we probably could make sure the users keep the same credentials. And thus also the LNURL-auth keys would not change (when used in Alby and others)
lndhub hashing: https://github.com/BlueWallet/LndHub/blob/fb023b02be53b47a0b5b837001fc7b08dd7f3bd1/class/User.js#L604-L606
go hashing: https://github.com/getAlby/lndhub.go/blob/689309a61d5ab0f1999d5f45d6e843b6f44be0b1/lib/service/service.go#L37
Users don't choose their own password for our lndhub accounts. Both login/username and password are retrieved from the LndHub API and then stored encrypted in the akkounts database.
So yeah, we could probably write a custom query to add records directly to the lndhub.go database perhaps? Even better would be a v2 endpoint where we can simply create users with both login and password as params.
Users don't choose their own password for our lndhub accounts. Both login/username and password are retrieved from the LndHub API and then stored encrypted in the akkounts database.
So yeah, we could probably write a custom query to add records directly to the lndhub.go database perhaps? Even better would be a v2 endpoint where we can simply create users with both login and password as params.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Probably just need to add some config values for the Rails app on this side of the story.
Ops issue here: kosmos/chef#455
This will actually impact/break lnurl-auth for people using it right now, so we need to tell them beforehand, or even give them a button to migrate the account.
Do you know if there is a way that we can keep the user's credentials?
lndhub.go uses a different password hashing algorithm I think.
can we actually make people to actively migrate? then we probably could make sure the users keep the same credentials. And thus also the LNURL-auth keys would not change (when used in Alby and others)
lndhub hashing: https://github.com/BlueWallet/LndHub/blob/fb023b02be53b47a0b5b837001fc7b08dd7f3bd1/class/User.js#L604-L606
go hashing: https://github.com/getAlby/lndhub.go/blob/689309a61d5ab0f1999d5f45d6e843b6f44be0b1/lib/service/service.go#L37
Users don't choose their own password for our lndhub accounts. Both login/username and password are retrieved from the LndHub API and then stored encrypted in the akkounts database.
So yeah, we could probably write a custom query to add records directly to the lndhub.go database perhaps? Even better would be a v2 endpoint where we can simply create users with both login and password as params.
then perfect. The /create endpoint accepts a login/password as params. So on lndhub.go users with the same login/password can be created.
Perfect, so we only need to migrate balances then. Thanks!
Almost there!
Done.