A security provider using the API of another Wappler app

Wappler General How To
1

There is an app A that is hosted on a private server. This server can only be accessed from one ip address. This ip address hosts a second server that is open to the Internet. App B is hosted on this server. App B communicates with app A only using the API. App A uses a security provider Wappler, using a database. How do I implement a security provider in app B so that it connects via the API to app A and the user can pass verification?

2

I believe this would be an issue as sessions would be based on the host of the Security Provider Project, likewise for cookies… Not sure how you would go about configuration with that in mind, not sure it can be done…? BUT then again I am often wrong.

3

The problem is not what you described Dave. App B has its own security provider, which will generate cookies and there will be no problems with the host either. There’s only one problem. How do I use the data source of App B in the security provider, not a database, but an API? I.e., in fact, I lack the fourth option when choosing type of data source in the security provider:

  1. Single
  2. Static
  3. Database

  4. API :point_left:

2 Likes
4

You know what I never ever saw this, thank you for the heads-up!

1 Like
5

I hope I’ve understood what you’re aiming for…

I would query the API to App A and if the correct response is give to authorise, perhaps with some kind of token, then perform a DB query on App B to get the username/password for the user (checking the token value at the same time) and use that query result in Security Provider of App B to log in

1 Like
6

Hi Ben. Yes, you have correctly grasped what I am striving for. However, there are weaknesses in your proposed solution that I am trying to get rid of. The fact is that I strive to ensure that no information is stored at all on the App B server. All information is stored exclusively on the server of App A. Therefore, in my project, the use of a security provider using a database in App B is not recommended.

After analyzing the possible options, I came to the conclusion that it is possible to achieve a solution in another way. I plan to abandon the use of the standard Wappler security provider in App B, and instead build a server action with all the logic of checks and redirects, which will verify data using the API of App A.

Before I proceed with the implementation, I would like to clarify the following question at the community and Wappler team: will there be some fundamental difference between a security provider and a server action that completely duplicates the logic of security provider checks and redirects?

Although I didn’t find any fundamental differences, maybe I missed something. I would appreciate your opinion.

7

You could still use Security Provider for App B but rather than it being a database one, you could have it being static/single, using a string returned from the API of App A (if authorised) as the password.

That way you can benefit from built-in Wappler page protection etc. and use security steps as you usually would.

8

Unfortunately, this is not a solution at all. Single/Static type of Security Provider implies a limited, pre-known number of users, with pre-installed static login/password pairs. This creates two problems at once:

  1. There are a limited number of users. In the case of a Single, it is only one user. In the case of Static, this is the number of users that was created before the deployment to the server. In my case, there are an indefinite number of users, which is determined only in App A.
  2. Since the Single/Static Security Provider does not support the use of dynamic data, then the data is pre-defined and stored on the application server. Yes, they are not stored in the database, but they are in the server files. As I wrote above, I’m trying to avoid this. I make sure that no data is stored on the App B server at all.
9

I think you misunderstand what I’m suggesting.

You create a single user with username and password (e.g. apilogin & A1g3PGt7!r$g)

You query the API with the user’s credentials and if it is authorised, you return A1g3PGt7!r$g to App B which you then use in the login step of the static security provider.

You will be able to have multiple users whose details are all stored exclusively on App A but can only ‘log in’ when the correct string is returned from the App B API step

10

That’s right, I got the idea right. The problem is that App A has a complex role model and most of the security should be based on the rights that are granted to the user (there may even be cases when user rights differ in the same user group). In this regard, a Security Provider with a static user will give practically nothing. You will still have to create a Server Action with a complex logic of checks and redirects that do not depend on the Security Provider. So I’m wondering if there is something in the Security Provider that I can’t recreate in a Server Action?

1 Like
11

Hello @Mr.Rubi.
I also want to use the API as a data provider for Security Provider. Have you found a solution?