After reading this article you will know:

  • For what we use authentication profiles;
  • How you can create an authentication profile;
  • Which three kinds of authentication profiles we offer;
  • What the differences between the three kinds of authentication profiles are;
  • All options you have when setting up an authentication profile.

Authentication profiles let you define which model(s) you want to use as a web users in the front end; how you'd like to call these web users and where not authenticated users should be redirected to when they're trying to access a page which requires authentication.

Creating a authentication profile.

Authentication profiles can be found in the settings menu in your builder bar.
When you're creating an authentication profile, you've got a several options, which we'll explain.

Profile

  • Name: The label of the authentication profile. When logging a user in or out, you can select a authentication profile to log in/out by selecting its name.
  • Kind: Authentication profiles are available in three kinds, of which you can create and edit two. Every app has one "Internal Betty Blocks Authentication"-kind of authentication profile and when creating a new profile you can choose between the kinds "Username / password" and "Custom authentication". A further explanation of the "Custom authentication" kinds can be found at the bottom of this article.
  • Login variable: The login variable defines the name of your user object, so how it will be labelled in your variable browser. If you look at the Internal BB authentication you'll see that the login variable is called current_user, stating that if you'd want to use the currently logged in user somewhere inside of an action or such, you can add the variable var:current_user from your variable browser. (Try it out!)

Settings

  • Login model: The login model defines the model which holds your web user. This is the model on which you've got your web users identification. Ask your self: Which kind of user will log in to my app? An employee? A contactperson? An astronaut? Or does your system not specify a function, but simply logs in a Person (or a Web user). Then that will probably be your login model.
  • Username / password: (Only when using the Username / password kind) The username and password define the credentials of your webuser. Which property of your login model should be used as the username and which should be used as a password. A username can be almost any type of textual or numeral properties, excluding properties like a Lists, multi line texts and number expressions.The best take for a username is an email address, in nine out of ten cases.
  • Expire sessions after this number of seconds of inactivity: What else is there to explain here? ;) It logs the (web) user out automatically if the user hasn't done anything for this amount of seconds. The default value is set to 86400, which equals 24 hours.
  • Login redirect to endpoint: This defines the Page to which a non-authenticated (web) user will be redirected to when trying to access a page which does require authentication.

Here's an example of the set up of an common authentication profile.

When you've set up your authentication profile is time to use it in your front end. Take a look at HowTo use authentication profiles on your pages to learn how you can apply your authentication profile to your page(s).

Custom Authentication Profiles

Applications are sometimes faced with a very complex login flow to authenticate different user profiles, maybe even based on different applications. In order to give you full control of these complex authentications we also offer custom authentication profiles.
Custom authentication profiles still offer you the possibility to define which model holds your web users and to name your login variable, but leave the authentication part up to you. This means that you can create your own way of authenticating your web user, using an action with a http request to a web service for instance. You only have to assign the proper value to the login variable in the right place in your action using the the "Authenticate & Login user" action event, of which you can see an example in the image below.

You'll only need to assign an object of your login model to the user variable in the action event. Everything up to that point can be adjusted to your specific case. The object of your login model will probably be generated somewhere in the action, but you can also fetch it at the event itself, based upon other available variables, as seen in the image above. As said, the next step is using your authentication profiles on your pages.

If something we've told you here is not quite clear, please let us know so we can help you with that and improve our documentation too. You're always free to contact us by the intercom logo at the bottom right of your screen!

Did this answer your question?