Web Form Message Source: Require Login
Is there a way to incorporate a login prior to accessing a TA5 Web Form? I had a look at the Oauth-> microsoft graph Action but I am not sure this can be incorporated into the Web Form Message source.
For Example user navigates to a webform, completes login, then has access to the form and results.
- 3 回复
- MMark Carpenter @mark.carpenter
If I understand the question correctly, there's a way to do this using multiple webforms. One webform message source for the Authentication, then another webform message source for the actual form. The first webform is the login, passes the user input to the automation that authenticates against userid/password you hold in a SQL table or if you have an external method to auth. Then upon successful completion, use the Webform Redirect action and apply it to the **Return action ** and that will take the user to the next webform. You can pass data to the next webform via the redirect action as well.
If my squiggles make sense, the diagram shows a system configurator. The user enters the Configurator Main Menu, which has a pull down to select which element to be configured. This is sent to the Configurator Main Menu Automation and depending what was selected, there's a Redirect to the correct automatoin in the Return, then the target web form comes up, the user enters the data, and the web forms automatoin comes up which essentially validates and stores the data, then it returns to the Configurator main menu.
HEre's a look at how the redirect is set within a Case statement, the Case values being the main menu pull down selections.
Hope this helps, hope I interpreted your question correctly, you can use this technique to create a password front end
That is cool!
I will attempt something like this if the folks at Parker don't have a solution/update for using Oauth. Would be cool if we could just use our microsoft account (for example) to login and be able to restrict access, maybe something like this?:
- M回复matty⬆:Mark Carpenter @mark.carpenter
Ya, TA rocks. My experience with the OAuth action is that you have to login as part of placing the action and in most cases TA will refresh the underlying 'refresh' or 'access' tokens. I wonder if Microsoft has a run time REST API sequence you could do an HTTP POST to that would cause the behavior on behalf of the particular user. It's always the authorization/login stuff that causes the most confusion and time to sort out!