Do we have to implement the logic/frontend ourselves? We like the extension as it means no extra dev time for us and we really don’t want to lose this.
2 Likes
No as it’s Universal Login dependent and it’s staying there so you won’t need to implement logic/frontend yourself.
Hi @oliver.wang, that link to the Docs tells me to use the Extension Hooks. I don’t see anywhere how to use actions for the DAE. But since hooks are going away, please, what do I do with the code that is currently in the DAE extension’s Write Hook? Do I leave that code there as per the DAE Docs or do I need to convert it to an Action? If I need to convert it to an Action then please tell me which action or action-trigger do I put the code into when I create the action for the write hook? And I need the same question answered for the other hooks for the DAE. The documentation that covers Hooks to Actions migrations does not cover this info, or if I missed this particular part in the documentation please let me know where I can find that. I am asking this question because I see there are 1 to 1 relationships between the tenant hooks to action-triggers, so converting the tenant’s hooks to actions are simple, but there are no triggers that matches the DAE’s Hooks and that’s left me with questions.
1 Like
DAE can run on Actions as well today and we encourage you to migrate Hooks-based DAE to actions The fact that DAE has an entirely containerized Hooks system has caused some confusion in that regard.
The ‘hook’ mentioned in our docs is not the extensibulity Hooks product itself
Delegated Administration: Extension Hooks, but more of a runtime Hook.
1 Like
Hi, sorry I didn’t notice the message about this AMA earlier. I have posted this topic Migrating Twitter email rule to actions about problems faced in getting the twitter email in actions and generally about how to get the social identity token used to call the social media API. Can you help?
Sorry for the late reply. We still need this, and there is no clear example to really think it is possible to actually spend more time trying to implement it, we have already spent time writing rules that will eventually not work.
There are other people complaining about the same, confusing messages about whether it’s supported or not (as pointed out by Chris), and I think something as basic as being able to link accounts under the same email should be something straightforward to implement, at least I shouldn’t have to spend dozens of hours writing code within the Auth0 platform, but in MY platform, why do I have to write such a large piece of code that runs within the Auth0 platform? that amount of effort and code should be spend only writing code in MY apps, e.g. customizing the frontend to show to the user their linked accounts and the components needed to trigger the linking or un-linking. “Actions” should only be used to customize behavior, not to write things that should be easy to enable from a SaaS product, e.g. it makes sense to write a bunch of lines of code if I want to allow unlinking only for a subset of accounts based on some user attributes.
There is no doc that explain what getManagementApiToken does as you did, and I don’t understand why we should provide a API token inside a Action that runs code “sandboxed” within the Auth0 platform, Auth0 already knows who I am, why I have to provide that token while other methods like api.redirect.encodeToken({... don’t require a token? what permissions / settings / claims has to have the token? I have written a few actions at this point and I didn’t need one, so why do I need one here and how do I get it right in this context? what about my other questions about undocumented constants used in the example? like REDIRECT_SECRET, what is it? The documentation is really incomplete.
It would be much easier if Auth0 would just provide an example that works, a simple but complete example in a repo, and moreover, an example that works, because there are a lot of examples in the auth0 repos that don’t work, I guess because they are outdated, like the examples to links account with the old “rules”, none of them work because of various bugs that are not worth the time to report because they are based on a product that is deprecated.
2 Likes
Hi @konrad.sopala, even with Universal Login I believe there are some pieces missing when moving from Account Link Extension to Actions. For example, the former provides a page, which tells the user that the linking is about to happen and allows them to proceed or abort leaving accounts unlinked. In addition, if the user logs in with another email for some reason, the extension redirects back to the login page with a custom flashMessage. I am not really sure that one can implement all this using only Actions and Universal Login. Am I missing something?
Does it make sense to simply rework the Rule that comes with Account Link Extension to an Action like people do in this issue? It seems highly unreliable to me as the extension seems to be based on webtasks which are no longer available for public use and the one for the extension could be dropped any time in the future.
I second @mariano.ruiz that it would be great if you guys had an instruction of how to migrate to the new approach, but preserve all the benefits of Account Link Extension.
Hi Oliver
Many thanks, your solution worked. 
We can now remove that legacy rule
Kind regards
Richard
1 Like
Following up the topic of (https://community.auth0.com/t/lastname-firstname-in-token-with-apple-signin/53076), is there any solution to include the first_name and last_name attributes (generated by Apple-SignIn) into the ID Token using Actions instead of Rules? Currently, I can only read family_name and given_name attributes using Actions at Event Object. I will need these attributes to fulfill the Apple Store Compliance on Apple Sign-In auto-complete user’s name.
Thank you!
Hello @gleb.ignatev thanks for the feedback, we will look into this as a future opportunities with the team
1 Like
This is true in the Post-Login Flow. However, I don’t think this ability exists in the Machine to Machine flow. Are there plans to add this ability?
Does this part of your response:
" The ‘hook’ mentioned in our docs is not the extensibulity Hooks product itself, but more of a runtime Hook."
mean that we shouldn’t try to turn these (Delegated Administration: Extension Hooks) hooks into actions?
i have a rule where i call
https://graph.microsoft.com/v1.0/me?$select=onPremisesSamAccountName
with the Azure AD Access token for users that are logging in for the first time, then i save the onPremisesSamAccountName to users App_Metadata.
is this something i can achieve using actions?
Hi @oliver.wang ,
what do u mean by using an Action with the latest API (v3)?
is there an version options for Action?
or u refer to calling the management API to get the custom attributes?
I’m currently implementing a passwordless login flow in my application and have encountered an unexpected behavior with the Post-Registration Action. My goal is to use this action to save the user’s ID in my database only after their initial registration. However, I’ve noticed that the Post-Registration Action is triggered after every login, not just the first time the user registers and also before the user enters their OTP. Is this expected behaviour?