Wappler Version : 3.9.7
Operating System : NA
Server Model: PHP
Database Type: MySQL
Hosting Type: AWS
Expected behavior
What do you think should happen?
Once your user has logged in, then all server restricts should work consistently.
Actual behavior
What actually happens?
Sometimes they all stop working and return unauthorised. It occurs completely randomly, and has taken me several weeks of working with my client to get a screenshot of the dev console to know more of what occurs.
When it happens, I think what goes wrong is consistent each time. Here is the process... lots of images to illustrate it are all below.
The user logs in okay.
A number of server actions are called which normally all run okay.
Occasionally, one of them (search_activities.php) returns unauthorised, and then all the subsequent ones return unauthorised too.
If the user restarts their browser and logs in again, it all works okay.
The problem occurs on average every 2nd-5th time they log in. It also seems to occur more for one client I have than another.
Am happy to supply any other information you need!
When the unauthorised problem occurs (all red calls are showing unauthorised)
(Note that while there are two calls to search_activities.php, the second one which causes the unauthorised to occur happens after some user interaction, whereas the first one which works okay happens as part of the login process)
Not sure if it matters Antony but you have no Permissions set for the Users, within the Restrict Properties/Permissions drop-down? We usually populate this with various Roles within Groups but yours appears to be empty? Probably nothing to do with it…
You shouldn't need to set the DB connection and security provider in the individual API file - they should be done under globals. Shouldn't make a difference but worth tidying up.
I've just had a similar issue whereby I had some queries that used the identity. When I updated the file, they no longer worked as they are referenced slightly differently. In your case, you would have used {{subscribed_user.identity}} but you would now use an identify step and just refer to it as the name you gave it (defaults to identity) e.g. {{identity}}. I usually put an identify step in global actions to save having to do so in each and every action file.
Are you sure the 'unauthorized' is always triggered by the same file? Could it be an amount of time where the logged in session is expiring? Also have you check the ones preceeding it (prices.php etc.) as they could be causing the logout but is first picked up by the search_activities file
Yes, I know about the best way to organise the database connection, but I have hundreds of apis created before doing it globally was a thing. @Teodor, could that be causing my problem?
I can’t see why any previous server action such as prices.php would cause a logout, but that is a good point, I can definitely take a look there…
I feel your pain. I went through a similar project recently that had a lot of APIs and it took a long time. The worst bit to account for was the change in reference from {{secprovidername.identity}} to {{identity}} in every query/insert/update
When you leave the field empty it just means that a user must be logged in and doesn't need a specific permission.
Does the problem only occur on the production server or do you also get the problem in development? It seems to me that probably there is a problem with the sessions on the server. The logged in user is being kept in a session and if that session somehow is expired or destroyed the restrict will return unauthorized. I would suggest to check how the sessions are configured on the server. If you have the remember flag set it will set an extra cookie with the user credentials, when the session then ends it will automatically login the user again, you could try to always set this cookie by setting the remember flag with the login always to true.
This has nothing to do with PHP or server knowledge. In the security provider options / UI where it says Remember just enter 1…
The Remember option is used to keep your users logged in even after they close the browser and come back again after that.
I remember i explained that same thing to you in a couple of your other topics as well.
