Background information on wrdauth
Cookies
The WebHare webserver can accelerate loginchecks if they're associated with a session whose ID is stored
in a recognizeable cookie. Such a cookie's name must start with webharelogin
, followed by characters in the range 0-9
, a-z
or -
and an optional _e
suffix. Any other underscored suffixes are ignored.
For any cookie matching the pattern, its encoded contents until the first percent sign are taken. This value if is looked up in th session cache. If the cookie matches a valid session and that session has already been authorized for the current access rule, the authentication script is ignored. The requirements this validation places on the cookie structure is also the reason for wrdauth cookies always atarting with 'webharelogin'.
The wrdauth cookie name (eg webharelogin-backend
) is used as the a base name for various related cookies
Login cookie
The actual login cookie has no suffix. It stores the sessionid, followedby a space and then an encrypted dataset containing the user's id and the login session parameters. This cookie will have a set expiry date if a persistent login was requested and will otherwise be a session-only cookie.
This cookie is a session cookie and is not readable from JavaScript.
JavaScript cookies
Some information about the loggedin user is made visible to JavaScript so static pages can eg. show
the user's firstname or email address as part of a 'logged in' indication. This data is stored in the _j
and _c
cookies.
The _c
cookie is a session cookie which contains the requested userinfo for use by JavaScript. The _j
cookie is a
long lived cookie which is used by the JavaScript code as a hint that the current user is logged in. The presence of _j
but not _c
may trigger a redirect to restoresession.shtml to verify that the login session is still valid and to rebuild
the _c
cookie with the requested user information.
The _j
and _c
cookies are not marked httpOnly
so JavaScript can access their contents and restore loginstate when
needed even on static HTML pages. These cookies do not contain actual login state so leaking their data will not allow third
parties to access login sessions. However, they may still contain personal information so your code should still be safe from
XSS vulnerabilities. (But this applies to all data available to JavaScript)
Login flow examples
Access rule logins
Login requirements defined by access rules (such as 'all users must login using their WebHare account')
are handled by webhare-auth.whscr
. The actual flow when accessing a site on an external host is as follow:
- User requests a login-protected page, eg
https://www.example.com/
- webhare-auth.whscr is invoked and does not see any cookie for the local domain.
The user is redirected to
https://webhare.example.net/.wrd/auth/gologin
with a logincontrol token containing instructions to redirect back tohttps://www.example.com/
after login. - gologin checks whether the user is logged in on
webhare.example.net
. If so, it will execute the afterlogin redirection and continues from step 5. If not, it will clear the login cookies and redirect the user to the WebHare interface to login - The user is requested to login.
- The user is redirected back to the original url, with a proof as URL variable
- webhare-auth.whscr is invoked again and processes the proof to log the user in.
When a site is previewed in the Publisher, the above approach doesn't usually work - login samesite restrictions will prevent the iframe from seeing the login cookies (step 3) causing the user to be logged out (and step 4 is also prevented in an iframe). In 4.22, step 2 will check for the 'preview' cookie and a sessionStorage flag to detect whether it's running in the Publisher iframe. If so, it will directly connect with the wrd challenge/proof mechanism (using postMessage) and use the proof to resume at step 5.
Login page considerations
A login page should check at rendering time if the wrdauth_logincontrol
variable is present on the
URL, and call the ProcessReturnTo
method on the WRD auth plugin to handle automatic login.
Eg:
// Perform return actions when already logged in
STRING logincontrol := GetWebVariable("wrdauth_logincontrol");
IF (logincontrol != "")
webdesign->GetWRDAuthPlugin()->ProcessReturnTo(logincontrol);
Login proof cleaning
When logging in with an accessrule or on a site other than where the login page is hosted,
the URL variable wrdauth_loginproof
is used to transfer login information. For access rules, this variable
is removed from the URL at first login, but in some cases (parallel logins, login site is hosted on the
same domain as the site the user is logging in) the wrdauth_loginproof
can remain on the URL. You might
want to remove it in these cases
Eg:
IF (GetWebVariable("wrdauth_proof") != "" )
Redirect(UpdateURLVariables(GetClientRequestURL(), [ wrdauth_proof := "" ]));