Is Kratos production ready?

[timorusky]

Hey, currently we are considering using ORY Kratos for our production systems (Kubernetes, native IOS apps).
In my opinion, the base of the project is already very advanced and easy to handle.
Other features that are still missing, such as non-localizable email templates, are more of a minor problem for us.
However, since we are a European company, points like GDPR compliance are very important for us. This raises the question: Can we simply program such features ourselves (account deletion, admin session management, account export etc.) by manipulating the database or does this interfere too much with the ecosystem? What is your opinion on this?

I'm already a fan of the project, looking forward to see more.

[aeneasr]

Hi there, you can find info about software maturity of individual projects here: https://www.ory.sh/docs/ecosystem/versioning

Generally speaking - ORY Kratos can be used in production, it does not have critical bugs, and it will most likely perform much better than any homegrown solution. However, what we can not guarantee, is that the migration process to newer versions will not include some work on your end (e.g. integrations, UI, updating email templates).

[TMInnovations]

Sorry from my side - I can only tell from my experiences with ory/kratos, where, for me, it was not possible to build up a registration or login flow without reloading the registration/login page. Like explained above, I also haven't been able to get a correct response after calling whoami client-side, due to the problems reported above.

My intention with https://github.com/TMInnovations/testorykratos is to give a working example for the use of kratos in an SPA.

Any information about how to better work with ory/kratos is appreciated. I'll definetely try to go the jwt way and - if that works better than sessions - the repo will be updated.

[vinckr]

Haven't gotten around to trying out your repo, but definitely try it out over the holidays @TMInnovations !
I think its great that you have motivation to contribute here and I want to help and support you getting everything up and running :).

[aeneasr]

Reloading is required in order to set up the cookies and prevent cross-site scripting and other potential attack vectors. Unfortunately, we have not yet found a way around that. Does that impede the UX too much?

[TMInnovations]

Thanks for your reply.

Wouldn't fetch() -ing with credentials and defined serverside access-control-allowed-origin headers be an option? This would avoid redirecting. The UX is okay, but after reloading all the angular services' states are gone - and this makes SPA developers lifes harder ;-)

Maybe we can find solutions inside the ory poject in the future. I'd definitely be down to contribute.

[aeneasr]

The UX is okay, but after reloading all the angular services' states are gone - and this makes SPA developers lifes harder ;-)

Right, that makes sense of course.

So we already support JSON payloads in the registration submit forms. Only the first request (selfservice init browser) has to be a redirect. But yeah it's on the road map to have a reference implementation (similar to RN or express) in 2021 and iron out all the smaller issues one might face.