Redirect a User After Login
Normally when a user logs in, the application redirects them to one of the defaults that are based on the context of what they are doing at the time. For example:
-
After clicking the Login link in the Commerce website header, the application redirects the user to their Account Overview page
-
After clicking the Proceed to Checkout option and logging in, the application redirects the user to the first step in the checkout process
-
After clicking the Log In To See Pricing link on a Product Details Page (PDP) and logging in, the application redirects the user to the PDP they were viewing
All such redirects use the same technique and, as a developer, you can change these defaults or create your own redirects. Login functionality relies on the following URL parameters:
-
origin
— The touch point the user was accessing before being redirected to the login page. -
origin_hash
— The page hash the user was accessing before being redirected to the login page.
When you want to redirect a user after login, rather than using the typical data-touchpoint
and data-hash
attributes in your templates, you need to generate a full href that includes the origin
and origin_hash
parameters in the URL.
Redirect a User Back to their Current Page
This example illustrates how to redirect a user to the page they were viewing at the time they clicked the Login button. To do that, you need to:
-
Dynamically generate the login URL
-
Dynamically generate the origin and origin hash
-
Dynamically update the link every time the user navigates around the site
-
Expose the URL into a link in the header
To generate the URL, use JavaScript to get the following information:
-
URL path for the login page
-
Name of the current touch point
-
Hash of the current page
When you develop your extension, place the following code in the entry point file:
define('Example.Extension', [], function () {
'use strict';
return {
mountToApp: function mountToApp (container) {
container.getLayout().on('beforeRender', function () {
function generateLoginUrl () {
var login = container.getComponent('Environment').getSiteSetting('touchpoints.login');
var origin = container.getComponent('Environment').getConfig('currentTouchpoint');
var hash = Backbone.history.fragment;
var loginUrl = login + '&origin=' + origin + '&origin_hash=' + hash;
return loginUrl
}
var Layout = container.getComponent('Layout');
Layout.addToViewContextDefinition('Header.Profile.View', 'loginUrl', 'string', function (context) {
return generateLoginUrl()
});
Backbone.history.on('route', function () {
container.getLayout().headerViewInstance.render()
});
})
}
}
});
The preceding code sample includes the following functionality:
-
Generates the login URL (
generateLoginUrl()
)If you want to log this URL to the console while on a Product Details Page (PDP), this function may return something like this, for example:
> "/sca-dev-2021-1/checkout.ssp?is=login&login=T&origin=home&origin_hash=Rishi-Jacket"
-
Adds a new value to the context object of Header.Profile.View (
addToViewContextDefinition()
)This new value needs to be surfaced in the header_profile.tpl. For Kilimanjaro and earlier versions of SCA, you can edit the link in the header_profile.tpl file to remove the
data-touchpoint
anddata-hashtag
values in thea
tag that generates the link to the login page, and set its href to the value of the returned URL.For Aconcagua and subsequent versions of SCA, you need to use an alternative like jQuery to remove the old link and add the new one.
-
Updates the header with a new value by listening to Backbone.history for hash changes (for example, when the user triggers a new route)
When the hash changes, the code accesses the layout object and instructs it to render the header view instance. Therefore, each time the user changes location, they see a correct link.