Mobile Apps: Security Enforcer

So how would one go about adding a login and page restrict using a security provider in a mobile app? It doesn’t seem to be an option and there are no globals because there is no Server Connect?

I think I have played enough with FW7 to get started but I need to know this first before I start. My App will require a login.

Be prepared for a bunch of mobile app questions! :wink:

Your mobile app works just like a website that just uses the server connect actions from another live Wappler site.

I figured that out for recordsets and data but not security provider? You can’t add Security Provider to a page to redirect to a log in page if not logged in?

Nobody has used security provider with a mobile app?

I think @george meant that you can use Security Provider from your Website API Server Actions.

For the Login Form just use the Server Action of the API project.

Yes, but it is the restricting accesses to pages and redirecting to the login page if not logged in. Security provider is not available in the App Connect at the page level.

I need the entire app to be password protected and if not logged in, show the login form.

Hey Brad. Use Security Provider on the back end in your Server Actions (before your DB and other Steps), then a Security Restrict. On the front end set the Actions to on Unauthorised redirect to ‘failed.html’ etc. That is how we do it. Simply protect all your Server Connect Actions with this method and then any user not authorised will be re-directed. This way you can apply restrictions to your HTML pages easily and effectively as well as to the Actions themselves inherently.

:wink:

4 Likes

That’s an interesting approach, @Dave. Thank you. I will explore that!

1 Like

Its exactly the same as on the front end essentially mate. I’ve been asking for Security Provider for mobile for a while, think I made a request some time back? But for now, and without custom scripting etc, its the way to go (as app pages have to be .html and there is no way to use restrict within this page type currently).

:wink:

1 Like

Man you have to love the Wappler community! Second to none in my opinion. As long as people ask questions the answers will come. So fundamental. No user here should ever be afraid to ask any question no matter the complexity. We all trade/learn through each others respective knowledge. Truly a great thing to be a part of.

5 Likes

I guess Wappler’s nodejs/express implementation manages this scenario much better than php implementation as you can run a SC on route and before content is rendered.

Just saying… :joy:

3 Likes

Our whole back end is being converted to Node. Then there is Node for Cordova too!

https://code.janeasystems.com/nodejs-mobile

1 Like

Music to my ears! Glad to have another power user in the node fam!

2 Likes

Its a learning curve that we need to adapt to and implement. The benefits are huge. Sometimes we don’t want to acknowledge these things but then we have to, would be stupid not to. Will certainly be mining you for information sooner or later @JonL :slight_smile:

1 Like

Are you sure about that? You should have seen the question I asked this morning in the extensions category before I deleted it. If I were my boss I would have fired myself instantly. No answers given.

@Teodor and other mods are witnesses.

1 Like

If you mean the security enforcer - you don’t need it on your mobile app.

You are not downloading any content pages as everything is already available in your app. So there is no point what do every to restrict html pages download and do redirects.

What you do is just login the user and then just show the different pages depending on its data.

So you are restricting server side your server connection actions with security provider to return only allowed data and then render it in the mobile app appropriately.

2 Likes

Further to Georges reply. In the data Project do not set the re-direct URL (in Security Provider) as it will be outside of your Design Projects root (two different Projects, hence using the Unauthorised Action in the pages) and will not work, the page will not exist in your Mobile application. The reason we protect all our actions is that we use the same code base for the publicly available Site portion of our app (both sharing the same design, App and Site).

1 Like

Yes, sorry … I did mean enforcer.

Thanks guys, I see I have to learn a new approach here. Not quite following what you guys are saying but I am sure it will make more sense when it comes time to actually attempt to build it.

Thanks again, much appreciated.

1 Like

Hi all, I am late to the party but getting my head around the security.
I read that cookies don’t work in the mobile apps so are you saying you use server side security to log then no more security restricts on further server connect/api calls to the back end?
I have been trying to mirror my web version but I keep getting user identity false as I assume when I move away from the login page the app doesn’t know I am logged in as there is no cookie.
So is the flow - log in, save the unique user id then use that as the identity for further server connect database queries?

Yes, that is what I have done.

On my home page of the app I have two sections since there is no redirect. One each for logged in or not logged in. So if user is not logged in (identity does not exist) it shows the login form. If it does exist it shows the main page content.

The only big drawback I have found since there is no redirect is that if a user stays on a sub page of the app and the session expires they can still use the app. What I did is set a scheduler to each sub page that after 6 hours I automatically send the app to the main page.

Since that main page doesn’t actually load in the background, when you open the app again it will then redirect as per scheduler and reload the page. If the session still exists it will load the content and if the session has been expired it will load the login form.