This message was deleted.
# general
m
This message was deleted.
d
Hello. You can extend an identity schema
c
I'm talking about things outside of the identity. "I'm aware some of these examples are explained in docs, I'm just trying to give my point across, I imagined something like this, correct me how this would be done in Ory User clicks sign up button, request goes to server, you validate request, if valid send off to Ory, if Ory is valid, add data to local DB, return new view to browser."
This I meant ^
d
I see. Kratos also has webhooks integration. The flow you described is correct. However, I want to mention a couple of things. Here’s an example of integration with external services during the registration 1. You need to initialize the registration flow. 2. You render the webpage for a client. 3. Client sends request 4. You validate the data using an external service, and if it’s valid you send the request to submit registration and continue the flow. 5. You can use webhooks to send data to an external service. 6. You can use admin API to update identity data in Kratos
In that case you’ll have two way integration with external service and Ory
c
So 4. I validate the data using external service and if it's valid I send the request to submit registration and continue the flow What if the registration fails, do I get that via hook? is all this the self-service flow? I'm not sure how this would look, an example app would help. The auth docs are great, but registration is barely explained.
d
What if the registration fails, do I get that via hook? is all this the self-service flow? I’m not sure how this would look, an example app would help. The auth docs are great, but registration is barely explained.
After registration: is executed when a registration was successful: ◦ Before persisting: runs before the identity is saved in the database. ◦ After persisting: runs after the identity was saved in the database. I’m not sure that Ory Kratos has a way to send data once the registration flow is unsucessful
c
This will probably be a requirement to be honest
d
You can open a feature request in issues
As a workaround, I can suggest implementing expired flows for the registration flow of an external service. The idea is simple. It would be best if you stored registration_start and confirmed fields. You can implement a janitor using these fields that removes unconfirmed flows.
m
@creamy-fall-97349 I’m not an Ory person, but I was curious - do you mean if your external validation service fails the validation you want to know about it?
c
Kind of sure
w
Dunno how other people handle it, but my team has an auth service that sits between the user and kratos. We store extra info in our own models / own migrations / own extra logic.
m
@creamy-fall-97349 gotcha
Could your validation service tell you about the issue? Or some logic that sits in between?
c
It's more like, I want to add extra validation such as ID checks etc before allowing someone to fully register which is automated in another system
a
FYI I did this and initially wanted to have a endpoint receive the /register first, take out some fields and pass the request on to kratos. This really was flakey and had too many issues so I wouldnt advise it. Instead, chuck the fields in the identity schema and then remove them afterwards with an after reg hook. It works "ok" for now.
ID checks - we do business checks. same thing, just use the after reg hook. we have a validation table so just block log in (another after hook) until that table says yup they passed validation
it's not great: getting any feedback on why they cant log in isnt clean but it works
c
Hmmm, maybe "but it works" isn't really what I want to open myself up to right now 😛 we're redeveloping our platform and still in the early stages of design, exploring options right now. Shame this isn't more supported