Brad, you should not be using security provider as a step in your server actions.
Security provider should be defined once under globals and then in your login step yyjuat add login step and select the security provider from the dropdown.
Same for the other server action, using the restrict step.
So fix these please.
Also what’s your workflow there? You log in and then what happens? What do you actually do with your other server action?
Alright, I cleaned that up. It does make more sense I like the identity under globals. Nice!
However it still doesn’t work …
When logged in it should reload the user details record as it does. You can see by the 200 status. And it should display a username which it doesn’t and it should also hide the login form if user details has records which it doesn’t.
Mar-01-2021 07-40-33
The fact that no user name is displayed and form remains visible suggests to me that the identity is not being read.
How have you defined this on the page? I.e. how is this done on the page?
Also - what is shown in the dev tools after the log in? Do you see the identify step returning there?
Well, showing the username is a simple binding from the recordset.
Hiding the form is done with dynamic attribute display --> hide when user details recordset has records.
So how have you done this Brad?
How is this recordset loaded? When? How is the data added on the page?
Also - what is shown in the dev tools > network > xhr after the log in? Do you see the identify step returning there?
<p>Logged in as: {{userDetails.data.query1.client_first}} <br>Identity: {{userDetails.data.identity}} <br> Form Status: {{formClientLogin.status}} <br>User Recordset Status: {{userDetails.status}}
Loaded on form success …
dmx-on:success="userDetails.load();formClientLogin.reset()"
And what’s the reply from the login server action then?
Interesting … the response is correct. Thats what it should be.
So that is correct, why is it not filtering the recordset?
Could you test with the App Connect update. Add an extra credentials attribute to the serverconnect component. The extra attribute should allow cookies to work with CORS. Also make sure CORS is enabled en a valid origin is entered.
dmxAppConnect.zip (22.6 KB)
Thanks @patrick,
I’m about to try this out. Can you explain more about the extra credentials and origin?
On the server connect component add an extra attribute credentials.
<dmx-serverconnect id="serverconnect1" url="/api/action" credentials></dmx-serverconnect>
Origin should be something like http://localhost:12345 for our internal webserver in Wappler. Setting origin to * will allow access from all hosts, but chrome blocks it when used with credentials, not sure on other browsers and with cordova.
Made the changes and no luck. Still. the same. 
You do have to completely rebuild and recompile your mobile app with the new app connect Brad, so it is included when you test it on your mobile device
Did you get a cookie inside the browser? iOS is a lot stricter with CORS then Android. The update should at least do something for the browser and android.
Does it set a cookie if you set the remember option in the security provider?
