Use Direct URLs to Open a Specific Dataset or Table

The standard way for a user to access SuperWEB2 is to start by loading the login screen, and then select the dataset or table they want to work with from the catalogue.

As an alternative, you can provide users with special URLs that take them directly to a specific dataset or table. For example, you can use this feature if you want to include direct links to specific datasets or tables on your website or intranet.

There is no specific configuration required to enable this feature. Construct the links as follows:

By default, /home will redirect to the catalogue. However, you can change the destination of /home by editing the value of link.home in the configuration.properties file.

If the URL contains non ASCII characters, these must be URL encoded (for example, if the character ä appears in the URL, this needs to be replaced with %C3%A4).

Some web browsers, including Chrome and Firefox, will do this automatically when you enter the URL in the address bar, but this is not the case with Internet Explorer. If using Internet Explorer you will need to explicitly encode the URL. There are many resources on the web that can assist you with URL encoding. For example: https://www.urlencoder.org/

How Do I Find the Dataset ID or Table Name?

Type	To Find The ID/Name
Dataset	Log in to the SuperADMIN console and use the cat command.
System Defined Table (a TXD file installed on the SuperWEB2 server)	Check the TXD filename. The value you need is the same as the filename (without the .txd extension). Direct URLs to system defined tables can only be used to access TXD files that are saved in the <tomcat_home>\webapps\webapi\WEB-INF\resources\txd directory. They cannot open TXD files that have been saved to sub-directories within the txd directory. If you wish to organise your saved tables into folders, you are recommended to upload them to the user data repository in SuperADMIN, rather than saving them on disk.
User Saved Table	Check the Saved Tables tab. The value you need is the name shown in the list of tables.
Shared User Saved Table	For the table, check the Saved Tables tab. The value you need is the name shown in the list of tables. For the folder, log in to the SuperADMIN console and use the cat command.

The IDs/names are case sensitive.

Will the User Need to Log In?

If you have audit logging configured, and someone who is not already logged in to SuperWEB2 accesses a direct URL, the audit logs will always show a login for the guest user account. This is the system checking if the guest account has access to the linked resources. If the guest account does not have access then the user is redirected to the login page and the audit logs will show an additional logout event for the guest user.   

See this page for more information about configuring guest access.

Using POST with Direct URLs

System direct URLs also support HTTP POST actions. You can use this feature to construct an external login form on your website that sends the user directly to a particular dataset or table after logging in.

The following example HTML code creates a login form that will direct the user straight to Retail Banking after logging in:

<form action="http://mysuperweb2.com:8080/webapi/opendatabase?id=bank" method="post">
    <label>Username</label> <input type="text" name="username" value="" />
    <label>Password</label> <input type="password" name="password" value="" />
    <input type="submit" value="Submit" />
</form>

You can copy this code onto your own HTML page. Simply change the action element on the <form> tag to the direct URL you want to use.

If you want users to be directed to the catalogue page, set the action to <server>/webapi/home. For example:

<form action="http://mysuperweb2.com:8080/webapi/home" method="post">
    <label>Username</label> <input type="text" name="username" value="" />
    <label>Password</label> <input type="password" name="password" value="" />
    <input type="submit" value="Submit" />
</form> 

Replacing the Standard Login Page with your External Login Form

You can use this feature to create a custom login form that is hosted on a different website to SuperWEB2. If you want to do this then you may also want to change SuperWEB2's logoutRedirectionURL configuration setting, which controls the location of the SuperWEB2 login page.

If you change this setting then your login page will completely replace the standard SuperWEB2 login page. Your page will be loaded:

• When a user attempts to access SuperWEB2 and is not currently logged in.
• When a user logs out of SuperWEB2.
• When a user's SuperWEB2 session times out.
• When a user attempts to access a direct URL that requires a login.

Your external login form will work even if you do not change the  logoutRedirectionURL configuration setting. However, if you do not change the setting then users will be redirected to the standard SuperWEB2 login page when they logout or their session times out.

To make this change:

1. Open <tomcat_home>\webapps\webapi\WEB-INF\web.xml in a text editor.

   

   Make a backup copy of this file before making any changes.

2. Locate the following section:

   XML

       <context-param>
           <description>
               The page which the user is redirected to if they do not have a valid login (timeout) or they clicked the log out button.
           </description>
           <param-name>logoutRedirectionURL</param-name>
           <param-value>login.xhtml</param-value>
       </context-param> 

   By default, the logout redirection URL is set to login.xhtml (the standard SuperWEB2 login page).

3. Change the parameter to the location of your alternative login page. For example:

   XML

        <context-param>
           <description>
               The page which the user is redirected to if they do not have a valid login (timeout) or they clicked the log out button.
           </description>
           <param-name>logoutRedirectionURL</param-name>
           <param-value>http://myserver/superweb2.html</param-value>
       </context-param> 

   

   If the URL contains non ASCII characters, then you must URL encode those characters.

   For example, to use the URL http://ru.wikipedia.org/wiki/Юникод you would need to encode this as http://ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4

   In most modern web browsers, including Chrome and Firefox, if you copy the full URL from the browser address bar, it will automatically copy the encoded form of the URL to the clipboard. Please note that this is not the case for Internet Explorer, so if using Internet Explorer you will need to explicitly encode the URL in order to use it.

4. Save your changes to the file and restart Tomcat or the SuperWEB2 service.

Note for Deployments with Non-ASCII Characters in IDs

SuperWEB2 supports the full Unicode character set. This means your table IDs are allowed to contain non ASCII characters (characters that are not part of the English alphabet).

If your deployment includes tables with IDs that have non ASCII characters in them (or it is likely that your users might create tables containing non ASCII characters in the table name), then you will need to make a change to the Tomcat server configuration to ensure that direct URLs continue to work: Tomcat must be configured to use UTF-8 encoding for URIs.

If you do not configure Tomcat correctly then system direct URLs containing non ASCII characters will not work.

This setting is not enabled by default. To make the change:

1. Open <tomcat_home>\conf\server.xml in a text editor.

2. Locate the following section:

   XML

   <Connector port="8080" protocol="HTTP/1.1"
              connectionTimeout="20000"
              redirectPort="8443" />

3. Add URIEncoding="UTF-8" to the Connector:

   XML

   <Connector port="8080" protocol="HTTP/1.1"
              connectionTimeout="20000"
              redirectPort="8443" 
              URIEncoding="UTF-8" />

4. Save your changes and restart the Tomcat service.

Some versions of Internet Explorer (including IE10 and IE11) do not fully support non ASCII characters in URL query parameters. If you are using the system direct URLs feature and your deployment has tables with non ASCII characters, then you are recommended to use an alternative browser where possible.