As Rules are fired only after authentication I cannot use a Rule to send a custom verification email on user Sign Up.
I have to send different email template with different subject and senders depending on the Client. When I started my implementation with a Rule I assumed I could use Client metadata to encapsulate some of the details of my email (e.g. email template id, sender, subject and so on).
In hooks my code is executed exactly when I want it to be but I have only access to user metadata and a context object which has info about the Connection only.
Is there a way to retrieve the client metadata of the application that registered the user?
Alternatively is there a way to have a Rule fire when a user Sign Up but does not login afterwards?
The rules are associated with a user authentication event, they run after the initial set of credentials has been provided, so there’s no way to run them for a user that just signed up.
In relation to the (un)availability of client context information within the post registration hook I believe this was a design decision so it’s not available at the moment and unlikely to be. The reasoning was that the user registration process should not be tied to a particular OAuth2 client identifier, in particular, if you need to take different paths depending on the way users enter/signup into your system then you should be explicit and include the necessary information directly associated with the user instead of overloading the client identifier to make that decision.
For example, if you signup users and include sufficient information as user metadata you can then react and customize the steps after the signed up without taking a dependency on a client identifier. In particular, if you have the same service that can be accessed through a web application and mobile application you’ll have different OAuth clients because of different platform requirements but conceptually the users should most likely not be treated differently just because they joined through the web vs mobile (this is just a general example, you could argue that you still have a use case to distinguish web vs mobile, but the point is that if you have that use case, you should still not overload the client identifier as a way to distinguish between them)