Trying to switch over the the GA post-login custom action but I can’t find the .actor property. This was included in the Beta version and gave access to values that were in the query string, body, hostname, ect. The property is now undefined, though the test json in the custom action editor is still showing it. We have Beta actions that make use of this data, but I can’t find it on the new event object and it is not listed in the new documentation. Also the updated documentation makes no mention of how to access secrets.
My issue is similar to what is described here:
Screenshot showing the test data in the editor still lists the actor
I have asked the team responsible for Actions about the event.actor object in beta vs. the GA version. I will let you know what I hear back.
Also, it looks like you can access secrets with event.secrets. I see that when you click on the key icon, it refers to context.secrets, but it looks like it is event.secrets as you can see in the Logs in this screenshot:
Thank you @stephanie.chamblee. I did find the secrets. I meant to point out that the the updated documentation for the post-login event does not mention of the .secrets property and should be updated. Also for updates the default json the gets populated under test tab should be updated to the GA event schema. The default still conforms for the beta event.
I heard back from the Engineering team who works on Actions. The test payload still supports the beta schema for Actions at the moment, but they will update it soon to reflect the GA schema to avoid this confusion.
The beta’s actor data is split between event.request and event.transaction. The team is working on adding the redirect_uri to event.transaction and that will be available soon.
This feedback is very helpful for the team. Thank you!
@stephanie.chamblee That doesn’t address my need for the query string and body that are on the actor property. On redirect to auth0 for authentication we add fields on the query string. The user is authenticated and then in the custom action we retrieve that value that was on the qs, do some authorization against an external api and add claims the the id/access token. In the cases of refresh tokens then we typically need the body property.
These values are available in the Beta. They are also available on a rule. We’ve been advised to use custom actions over rules and have developed as such and now those properties are not available. What you specified in you last post doesn’t solve my problem, and we’ve spent a fair amount of time developing and testing custom actions just to have the rug pulled out from under us. So I need to know if the properties I need are going to be there for GA as they are in the beta and on a rule or not.
I’m sorry to hear of your frustration regarding the schema change. I’ve passed on your feedback to the team. They’ve explained that they are making an effort to avoid exposing the query and body params directly in Actions so that they are able to deliver new features at a faster pace than what was possible within rules.
At this time, the query object is not available in actions, however, the team is working on a solution for exposing custom parameters within Actions. Unfortunately, there is not a public release date for that enhancement yet, but your feedback is very helpful in determining the priority.
Hello @meyc, Actions has gone GA today. Please take a look at the final Post Login Event Object and our documentation on the Programming Model Changes. I think that you will find that your use-case is well supported!
Is this how the query and body will be accessed long-term? I discussed this with a couple members of the Auth0 Actions team this past Friday, and they were looking at possibly providing a “params” property that would have the values of the query or body without having to check both properties.
Hi @meyc thanks for taking the time to talk to us on Friday. For the time being we are not planning to expose a sort of union of the query and body parameters. One of the challenges we’ve seen with this sort of feature in the past is that the order of application becomes a source of confusion and sometimes friction. In other words, for a request having both a query and body parameter sharing the same name, which one ‘wins’? We’re trying to build a model with the right primitives before trying to introduce any higher level concepts.
With the launched programming model, you might find something like this gives you the power to choose the order of application between query and body. Note also that they will both always be objects.
// Whichever value is spread in last will 'win'.
const combinedParams = {
...event.request.query,
...event.request.body,
};
