https://www.ory.sh/ logo
#general
Title
# general
t

thousands-church-11419

01/18/2022, 1:58 PM
👋 hey ory team, we’re interested in getting someone from ory to help us migrate from firebase to (selfhosted?) ory - is that service available and if so, who can I talk to to get the discussion started?
m

magnificent-energy-493

01/18/2022, 2:09 PM
Hello Michael, We offer community support for all self-hosted deployments here #self-hosted and on GitHub discussions. I would also personally offer to help you with documenting a migration from Firebase. We also have some more users who are in that process, maybe there is an opportunity to learn from each other. For our paid Ory Cloud service we also offer more hands-on engineering support.
❤️ 2
m

microscopic-forest-58980

01/18/2022, 2:11 PM
I mean, I love Auth0, but that offered help would be £1000s in consultancy from them
m

magnificent-energy-493

01/18/2022, 2:22 PM
I have a rough draft for migration from Auth0, I think some of that could be ported to Firebase as well. At least the considerations for the beginning and all other steps not directly related to Auth0. I will see to get it in a shape for first release next week, can't promise earlier. It is not going to be a drop-in/no-brains guide (yet), but that is the end goal 🤗
t

thousands-church-11419

01/18/2022, 2:26 PM
To be clear we're happy to (and really asking to) pay $$$$s in consulting fees so that we can get this done in a timely manner
👍 1
m

microscopic-forest-58980

01/18/2022, 2:27 PM
Agree, I'm sure it will be worth it :)
t

thousands-church-11419

01/18/2022, 2:27 PM
We're ok with using ory cloud, although some of the features we want are only supported in self hosted version
Thus why we'd chose self hosted. Ideally we'd like the support to be both anyway since there are some thing we wouldn't move to ory cloud anyway but I'd be nice to have a point of contact for those workloads as well
A random example - we're using oathkeeper with envoy as like a gateway into our services 😅
m

magnificent-energy-493

01/18/2022, 2:32 PM
I see, that sounds interesting; can we set up a short meeting to talk it through: https://meetings-eu1.hubspot.com/vincent-kraus ?
👍 1
t

thousands-church-11419

01/18/2022, 2:53 PM
Done thanks
🤗 1
j

jolly-magazine-7609

01/19/2022, 12:55 PM
The default hashing algorithm used in firebase is a modified scrypt. I assume in theory, when an account is imported into kratos, the hash and the hash parameters used in the firebase project can be added to the
config
field of
identity_credential_types
. The next password attempt could verify the hash according to the content of the config field and if it's correct, rewrite it to be the regular password hashing algorithm configured in the kratos setup. There would need to be some code to facilitate checking importable hash algorithms that aren't ones you can typically select for normal kratos usage. I haven't gotten around to trying it yet.
t

thousands-church-11419

01/19/2022, 12:56 PM
ah, in our case we don’t want to import the passwords, our challenge is actually going to be the user_ids, because they’re string (some base64 thing) in firebase, but uuid in kratos
j

jolly-magazine-7609

01/19/2022, 12:58 PM
I would imagine you'd have to map it via the email address
t

thousands-church-11419

01/19/2022, 1:00 PM
Well the problem we have is that we’re joining tables on user_id, so we already have data that says “123” created “x” and so of course, while kratos can generate a new ID, it won’t match anymore
j

jolly-magazine-7609

01/19/2022, 1:06 PM
you'll have to join with a table that has both the firebase id and the new kratos id. Maybe there is a table that currently has the primary key as the firebase id that will need a new column for the kratos id
t

thousands-church-11419

01/19/2022, 1:23 PM
Yeah something like that, we’re all in on microservices though so it's not as easy as running a migration
Or it might be - there might be a way with mutators in oathkeeper or something
2 Views