Login in

Principle

The XTEND login is based on a Web service call via user action.

This document describes the implementation of the login function in the ASAMPLE reference site.

In this example, the login sub-program validates the signature and sends the information to the user account:

• The user identity, which is stored in the session entity
• The shipment address list, which is stored in the form of entities of type "Action" in order to be displayed

If the XTEND site was created from a copy of the ASAMPLE site, the setup records are already present.

Otherwise it is possible to either create them or to copy them one by one from the ASAMPLE site via the X3 action button 'Copy'.

Procedure

1. Creation of a "Web page" (ALOGIN) to enter the user code/password.
    This page is displayed in secured mode (HTTPS)

2. Creation of an interface (AXTDLOGIN) for the login Web service call

3. Creation of entities (ASHIPADDR) to store the user account information

4. Creation of a "Web action" of type "Login" (ASESSLOGIN)
    Setups upon entry: the user code and password.
    These setups are "mapped" on the setups upon Web service entry.

5. Creation of a "dynamic link" token (ADLKLOGIN)
    Inserted in the HTML page ("Validate" button) to trigger the user action

6. Creation of a "Web page"(AUSERACCOUNT)
    Displays the information of the user account sent by the login sub-program
    This page is displayed in secured mode (HTTPS)

Login management for the ASAMPLE site

Functioning of the login processing for the ASAMPLE site

The XTEND login information is managed in the X3 user record.

An XTEND user is declared as X3 user for which the checkbox 'Web site connection' was ticked.

Its Safe X3 Was profile is recovered and loaded in entity ASESSION.AUSERPROFILE.

X3 setups

Step no. 1 - Creation of the interface

4GL processing

The file AYTXTLOGIN.src contains the sources of the login program.

The user account data are programmed "in hard code" in the processing.

The sage/sage accounts are used to log in without password control.

Example
    Login (info) processing of the ATEMPLATE site

The sub-program record

The sub-program record AYTXTLOGIN describes the setups of the sub-program.

Refer to the document user action for further details on the login program.

The other setups (AX*) are mandatory setups for any XTEND login sub-program.

Before proceeding, it is necessary to make sure that the sub-program is published with the publication name AXTDLOGIN

The interface record

   1. Create an AXTDLOGIN interface record of type "Sub-program action"

   2. Select the publication name AXTDLOGIN

   3. Verify that the access is not protected

   4. Check the display of all messages

   5. Save and Validate

   6. Generate access

•  In this example, the setups concerning the shipment addresses (SHIP*) are grouped in the group named X3LOG. Another group could have been used if the dimension were different from the group containing the other AX3* setups.
• The other setups (AX*) are mandatory setups for any XTEND login sub-program.
• AXLOGCOD / AXLOGVAL: Additional information on the user, of type key/value, which are stored in the XTEND session (ASESSION section).
  Eg.: NAME/DUPONT,PHONE/0476232526,COMPANY/SAGE...

   7. Generate all the fields of the interface
      Refer to menu 'Tools/Field token creation'

Field not described in the interface

Fields concerning the user identity are displayed in the form of a key/value list (AXPARCOD/AXPARVAL) and are hidden in the sub-program setups (NAME, FIRSTNAME, PHONE, EMAIL).

It is thus necessary to declare these fields via the XTEND function 'Field token'.

Step no. 2 - Creation of the entities

User identity

The fields carried by the setups AXPARCOD/AXPARVAL (key/value) are added automatically by the XTEND server in the ASESSION user session.

The use of key/values makes it possible to limit the number of setups in the sub-program.

Shipment addresses

Create entity ASHIPADDR of type Action.

Refer to menu 'Tools/Entry help'.

This entity is then used in the return mapping of the login action.

Step no. 3 - Creation of the Web action

Setup reporting

Create an action ASESSLOGIN of type Login with the fields AXUSERCODE and AXPWD as setups upon entry.

Deletion on start'
    unchecked: in order to delete the entities only if the login is validated.

Activity tracking
    Yes: for all action calls to be recorded in a log file

Active on reload
    No: to not recall the login if the user presses the F5 key

Mapping of setups on entry

This aims at matching the XTEND field with the setups for the login web service call.

In this example it is only necessary to map setups of action AXUSERCODE, AXPWD.

The entity code is not to be entered in order to "map" action setups.

Mapping of setups on exit

This aims at creating the entity of type Action ASHIPADDR using the data sent by X3.

This entity is of multi-type since it is based on a group of multi-dimension setups (AXLOG_PAR).

The entities of Action type are stored for later use during the user session.

They are automatically re-created upon each action call.

Step no. 4 - Creation of the dynamic link

The dynamic link ADLKLOGIN is the token that is inserted in the login button (tag <input>). It is used to define the destination page (current page here), to associate the action ASESSLOGIN and to value the setups.

General setups

Activity tracking
    Yes: so that any click on the link be recorded in the log file

Force the http post mode
    No: Since an action with setups is associated with the dynamic link, the request is sent automatically in POST mode

Current page
    Yes: The result (user information is displayed in the current page

Action
    Code of the action to trigger (ASESSLOGIN)

Control of Web fields
    Yes:  for the user code setup to control automatically the fields in mandatory entry
    No:  the password setup authorizes the entry of empty passwords

Action setups

This aims at declaring the login action setups and at indicating the method to value them.

AXUSERCODE, AXPWD
    'Mand. Web fld': Mandatory entry in Web field
    'Web field': contains the input tag name (attribute name)

The entry control is active only if the option "General tab/Control Web fields" is ticked.

The query is sent to the XTEND server only if:

• the user valued all the mandatory fields
• the entered data is correct for the fields of type date and numeric.

The control is carried out by the XTEND JavaScript library.

Step no. 5 - Creation of the section tokens

The section token ABLKSHIPADDR is used to display entities ASHIPADDR representing the shipment addresses.

Type
    Multi record: Performs an iteration on all ASHIPADDR entities and positions each entity at the top of the data context stack and then carries out the child tokens

No data
    Nothing displayed: If entity ASHIPADDR does not exist, the section and the child tokens are not taken into account

Entity
    ASHIPADDR: Code of the entity to display

Line by section
    10: Displays maximum 10 ASHIPADDR entities in the page

Cell by line
    1: Displays one entity by line

Style by line
    oddLine and evenLine: Styles to define in "my.css" file to alternate the background line color

It is not possible to define selection criteria on the sections selecting the entities stored in the XTEND server memory, that are of Session or Action type. The section selects automatically all entities.

The selection criteria are only applied to entities of type "Data access".

Step 6 - Creation of Web pages

Login

Create the ALOGIN Web page.

Default page
    Associate the login.html file.
    The file must be present on the X3 server and can be selected by the F12 key.

Protocol
    Https: Used to indicate that it is necessary to encode the query data (see HTTPS configuration)

Main section and background section
    None

Protected access
No: Used to indicate that this page is in open access (anonymous)

Activity tracking
    Yes: Used to record the page display in a log file

User account

Create the AUSERACCOUNT Web page.

Default page
    Associate the file account.html

Protocol
    Https: Used to indicate that it is necessary to encode the query data

Protected access
    Yes: Used to prevent anonymous users from accessing this page

Activity tracking
    Yes: Used to record the page display in a log file

Step no. 7 - Site validation

After modification of the X3 setups, it is advised to validate the site as a whole in order to build the XTEND server dictionary via function 'Web site validation (AYTFCYGEN)'.

Verify that the XTEND site is published, that is that the field "Publish the site" of the "Web site" record is checked.

HTML page

Link to the page

Insertion of the "Web page" token ALOGIN in the left menu to display the page.

    <TD class="button"><A adx="ALOGIN">Login</A></TD>

In order to make a simple link (without action nor selection) to a Web page via an anchor tag, it is sufficient to insert a token of type "Web page" in the tag(<a adx="PageWeb"></a>) in order to limit the number of "dynamic link" tokens.

Login/logout menu management

The content of the left menu is modified dynamically depending on whether or not the user is logged in.

The conditioned link token ADISPUSERLOGGEDIN is used for this purpose. It displays the content of the section (child elements) if the user is logged in.

 <!adx="ADISPUSERLOGGEDIN">
 <!--Left menu for authenticated user-->
        <TR>
          <TD class="button">
                <A adx="AUSERACCOUNT">Compte</A>       
          </TD>
        </TR>
        <TR>
          <TD class="button">
                <A adx="ADLKLOGOUT">Logout</A> 
          </TD>
        </TR>
<!adx="ADISPUSERLOGGEDIN">
<!adx="ADISPUSERLOGGEDIN:xnot">
 <!--Left menu for anonymous user-->
        <TR>
          <TD class="button">
                         <A adx="ALOGIN">Login</A>
          </TD>
        </TR>
<!adx="ADISPUSERLOGGEDIN">

Login entry

Creation of the entry fields <input type="text"> for the user code and the password.

When no attribute name is specified in a tag <input> it is generated automatically with the adx token name.

In case of an entry error discovered by the XTEND server of the X3 application, the setup xrc(<input adx="TokenName:xrc">) is used to display again the last value entered. It makes it possible to avoid loosing entered data.

Upon password entry, the attribute name="AXPWD" is added since it is not necessary to insert an adx token to display the password again.

Creation of a button<input type="button"> 'Validate' and insertion of the token 'ADLKLOGIN' which triggers the login action.

All the buttons <input type="button"> containing adx tokens MUST be of type 'button'.
The type submit should not be used.

  <tr>
    <td><b>Code:</b></td>
    <td> <input name="AXUSERCODE" type="text" adx="AXUSERCODE:xrc"></td>
    <td><input type="button" value="Valider" class="button" adx="ADLKLOGIN"></td>
  </tr>
  <tr>
    <td><b>Password:</b></td>
    <td colspan="2"> <input type="password" name="AXPWD">    </td>
  </tr>

The token ADLKLOGIN displays the page AXUSERACCOUNT if the signature is validated by the X3 sub-program.

A user action is considered as validated if no error message was sent by the Web service call.

The error messages are sent in 4GL via sub-program ADDMESSERR (Call ADDMESSERR("Message") From AWEB)

X3 messages are displayed via the token AXUSERMSG.

Ex: <span id="userMsg" class="userMsg" adx="aMsgUser"></span>

User account display

The AUSERACCOUNT page displays user account information. The data comes from the mapping of setups sent by the login sub-program:

• ASESSION stored user identity
• address list (entity ASHIPADDR)

Displaying identity data consists in positioning "Web field" token without specifying the data context (section token) since the session data can always be accessed in a Web page.

  <tr>
        <td><b>Nom:</b></td>
        <td adx="NAME"></td>
  </tr><tr>
        <td><b>Prénom:</b></td>
        <td adx="FIRSTNAME"></td>
  </tr><tr>
        <td><b>EMail:</b></td>
        <td adx="EMAIL"></td>
  </tr><tr>
        <td><b>Tél.:</b></td>
        <td adx="PHONE"></td>
  </tr>

Displaying the shipment address list consists in positioning the section ABLKSHIPADDR which makes an iteration on the address list and thus makes it possible to create as many lines in the grid as addresses in the list.

For each line it is possible to create as many cells as data to display thanks to a tag adx="SHIP*".

<table width="100%" border="1">
    <tr  class="tabTitle">
        <th><small><b>Adresse1</b></small></th>
        <th><small><b>Adresse2</b></small></th>
        <th><small><b>Ville</b></small></th>
        <th><small><b>Code postal</b></small></th>
    </tr>    
<!adx="ABLKSHIPADDR">  
    <tr adx="aLineStyle:xattr=Class">
        <td><small adx="SHIPADR1"></small></td>
        <td><small adx="SHIPADR2"></small></td>
        <td><small adx="SHIPCITY"></small></td>
        <td><small adx="SHIPZIP"></small></td>
    </tr> 
<!adx="ABLKSHIPADDR">         
</table>

In order to display the lines of a grid with alternated colors, an adx token is set in the <tr> tag.
<tr adx="aLineStyle:xattr=Class">

aLineStyle contains the name of the class and xAttr=Class indicates that it is necessary to value the class attribute with the value of field aLineStyle.

The css classes (aLineStyle) that are applies to the grid lines are defined in the section setup record.

Display of the page description

<!adx="ABLKDOCHTML">
   <div adx="TEXTE">
   </div>
<!adx="ABLKDOCHTML">