Hiding Intershop UUIDs in URL rewriting


A common problem for URL rewriting rules in Intershop are unique identifiers. Intershop uses UUID as the object “primary key”, so they naturally appear as parameters in the URL. The most common example is related to product details, but may also affect other objects handled by Intershop, such as orders, vouchers, catalogs etc. The need to remove UUIDs is usually driven by a search engine optimization or marketing efforts to use short, user-readable URL. This blog entry describes a solution to this problem. If you look for more information about URL rewrite mechanism in general, it can be found at the following blog entry about Enfinity URL rewrite mechanism pitfalls.

Even though identifiers like UUID are often sent as form parameters, they are rarely wanted in URL, whether it’s for the safety reasons (to avoid “publishing” unique identifiers of objects in your database) or simply because it looks ugly (something like “CiBhj.mk79hijglmnu3i” surely doesn’t look impressive to a customer writing down or bookmarking a link on the site).

Rewriting calalog UUID

Typical example of this problem is a catalog identifier. Since catalogs are potentially not uniquely identified by their URL rewritten name (due to rules of transliterating language specific letters), they usually need to be retrieved by the UUID. Since UUID is not not available any more in the short URL, a solution is to add a custom attribute to catalogs (named “ShortURL”) by which we could match the catalog and retrieve it for further processing. The catalog browsing logic has to be extended with a simple piece of code that checks if parameter “ShortURL”has been received in the URL and then retrieves the catalog with a matching attribute. A matching set of rules for such URLs would look something like this:


This rule will match all URLs on a specified hostname which contain the action ViewStandardCatalog-Browse. Since those URLs will always contain the UUID of the catalog, in descriptive URL UUID is removed (${d.CatalogUUID} hides a parameter) and a dictionary value #Catalog:ShortURL# containing the “ShortURL” custom attribute value is used instead. When incoming request is processed, expanding the descriptive URL the process will be different. In descriptive URL catalog name will be matched by the regular expression “([^\\?]+).*$” and used as a back-reference to create a standard Enfinity URL (CategoryName=$2) with “CategoryName” as a parameter. The extended browsing logic will recognize the parameter and try to retrieve the catalog by its name. Assuming a right catalog name was provided in the URL, a specified catalog will be presented to the user.


This way, UUID parameter will be hidden from the customers and replaced with a value that back office administrator can support through the site back office for each catalog. Similar approach can be done with any other parameter or component of the URL that should not be exposed in the descriptive URL.