This is an old revision of the document!
Portal user login
A common use case for coreBOS is to permit our clients or employees to access information in the application and even manage certain parts of that information. This is what we call a Customer Portal application or, simply external applications because there are so many possible use cases.
The most typical scenario is for clients to be able to access some application where they can create issues (Support Tickets) about our service.
Other use cases are:
- client access to their invoices
- client can create purchases (although this is usually better through an e-commerce integration)
- employees can access their monthly salaries
- employees can access protocols and documentation
- employees can manage projects and project tasks
- employees can add time control records
the list of functionality goes on.
These are just some examples of external applications. In some cases, we can use ONE normal coreBOS user to access the information. The idea would be that we create a login page where we validate our client/employee using the authenticateContact endpoint, we access coreBOS using a normal user, then we restrict all the queries and operations based on the contact that has logged in.
The profile of the authenticateContact endpoint looks like this:
| Purpose: | Validate a contact in a coreBOS install |
|---|---|
| Profile: | authenticateContact(email:String, password:String):LoginResult |
| Send Type: | POST |
| Parameters: | email: the registered email of an active contact in coreBOS password: internal password set when activating the contact for portal access |
| Returns: | LoginResult can be the contact web service ID if access is granted or false if not granted |
| URL Format: | http://corebos_url/webservice.php?operation=authenticateContact&email=[email]&password=[password] |
| Comments: | This method is deprecated and should not be used anymore. |
The problem with this approach is security. Since we are using a normal user, the permission system is in effect, but this user has to have, at least, access to the information that ALL the contacts need to access. For example, no matter what contact logs in, we are using the same coreBOS user, that needs to have access to all the tickets in the system. If the contact using the application finds a way to execute a query without restrictions they will be able to access the information of other contacts.
This is a serious issue in the javascript world. A react or vuejs application sends all the code to the browser where the contact will be able to manipulate and override whatever they want.
This is where the Portal User Login comes to play.
CP Restrictions: Web Service Documentation authenticateContact loginPortal sendRecoverPassword
