Can I restrict access to the configurator to specific users?

If you don’t want your configurator to be publicly accessible, you can restrict access. There are several reasons to do this:

• Only certain known individuals should be allowed to use the configurator.
• Only customers who are already logged in to your store or your ERP system should be able to access the configurator.

Auth0

We use the well-known authentication service https://auth0.com/ for this purpose.

You can set up a free account there.

• Then create an Application.
• Under Settings > Application Type, select "Single Page Application".
• Under Settings > Allowed Callback URLs and Allowed Web Origins, "https://k3.objectcode.de/app".
• Set Credentials > Authentication Method to "None".

Under Settings, make a note of your application’s "domain" and "clientId".

Integrating Authentication Systems

This is the real highlight of Auth0: Auth0 doesn’t have to manage users itself— it can integrate with your existing authentication system and handle login through it. The configurator only communicates with Auth0; you select which system is behind it in Auth0 under Connections. You can also have multiple systems at the same time.

Typical scenarios:

In-house user management

You manage authorized users directly in Auth0. This is easiest for a manageable, known group of users.

• Enable the "Username-Password-Authentication" connection in your application.
• Create users under User Management > Users > Create User (email + password, "Username-Password-Authentication" connection).

WordPress and Other CMSs

For the relatively common scenario where you want to use WordPress, you can use Auth0’s free plan.

First, turn your WordPress site into an "OAuth2 server":

• Install and activate this WordPress plugin.
• Click "miniOrange OAuth Server" in the sidebar
• Choose a "Client Name" and save.
• Leave this page open; you’ll need information from it.

Now set up the connection in Auth0:

• Click Authentication > Social
• Click "Create Connection"
• Select the last option, "Create Custom"
• Give the connection a name.
• Copy the following from the WordPress plugin page:
  • Authorization URL
  • Token URL
  • Scope
  • Client ID
  • Client Secret
• Make a note of the "Userinfo Endpoint."

Finally, enter this code into the "Fetch User Profile Script" field, replacing the "Userinfo Endpoint" with:

function(accessToken, ctx, cb) {
    request({
      method: 'GET',
      url: '<Userinfo Endpoint>',
      headers: {
        Authorization: 'Bearer ' + accessToken
      }
    }, function(err, resp, body) {

      if(err) {
        return cb(err)
      }

      if(resp.statusCode !== 200) {
        return cb(new Error('StatusCode:' + resp.statusCode));
      }

      let bodyParsed;
      try {
        bodyParsed = JSON.parse(body);
      } catch (jsonError) {
        return cb(new Error(body));
      }
      const profile = {
        user_id: "anonymous",
        name: "none"
      };
      cb(null, profile);
    }
  );
}

• Click "Save changes"
• Click "Try Connection"

You should now be redirected to your website and able to use it. If this is successful, you can add the new "Social connection" to your "Application."

ERP, Online Store, or SSO

If you want to allow only users who are already logged into your ERP, online store, or company portal to log in, integrate it via Single Sign-On:

• Under Authentication > Enterprise > SAML, set up SSO with your ERP, online store, or website.
• Under Authentication > Social, you can also authorize providers such as Google to use the service.

Enable in K3

• In K3, go to the Options of your configurator.
• There, select the Configurator Access tab.
• Enable login.
• Enter the "domain" and "clientId" of your Auth0 application.
• Save your changes and don’t forget to publish.

This ensures that the live version of your configurator prompts users to log in via Auth0.

Passing Data to the Configurator

You can have data transferred to the configurator for each logged-in user— before the configurator loads. This ensures, for example, that the correct price list is immediately set. The following data can be passed:

Data	Effect in the Configurator
Price List	Selects the price list (using its code).
Dealer	Launches the dealer configurator (using the dealer code).
Contact Information	Pre-fills the contact form (name, email, phone, address, etc.).
Features	Any preselections (e.g., color, width) via the variable keys.

How Data Transfer Works – Regardless of the System

The principle is always the same, regardless of whether you have integrated your own user management system, WordPress, or an ERP:

1. The configurator expects the data in fixed "compartments" (Auth0 calls them Claims) with the namespace https://k3-konfigurator.de/. These slots are always the same: pricelist, dealer, attributes, contact.
2. A small action in Auth0 places your user data into these fields. The action acts as the translator between your system and the configurator.
3. Where the data comes from depends on your system—which is why the action looks slightly different depending on the situation. The configurator isn’t aware of this; to it, the fields are always populated the same way.

The name and email are automatically retrieved from the login—no action is required for this.

With your own user management

Here, you maintain the data directly on the Auth0 user. The action simply copies them into the fields—it is universal and never needs to be changed.

Step 1 – Create an action (one-time):

• Open Actions > Library > Create Action > Build from scratch.
• Name: e.g., K3 Claims, Trigger: Login / Post Login.
• Replace the code entirely with:

exports.onExecutePostLogin = async (event, api) => {
  const ns = "https://k3-konfigurator.de/";
  const k3 = (event.user.app_metadata && event.user.app_metadata.k3) || {};
  for (const key of Object.keys(k3)) {
    api.idToken.setCustomClaim(ns + key, k3[key]);
  }
};

• Click Deploy.
• Open Actions > Triggers > post-login and drag and drop the action K3 Claims into the workflow. Click Apply.

Step 2 – Maintain Data per User:

For each user, under User Management > Users > [User] > Metadata > app_metadata, enter a k3 object—including only the fields you need:

{
  "k3": {
    "pricelist": "wholesale",
    "dealer": "dealer-42",
    "attributes": { "color": "red", "width": "120" },
    "contact": {
      "name": "Erika Mustermann",
      "email": "erika@example.com",
      "phone": "+49 151 12345678",
      "company": "Muster GmbH",
      "taxID": "DE123456789"
    }
  }
}

Minimal example – only a phone number, name, and email are retrieved from the login:

{ "k3": { "contact": { "phone": "+49 151 12345678" } } }

For integrated systems (ERP, online store, CMS)

In this case, your system already provides the user data during login—in the user profile. The action reads the relevant fields from this profile and places them in the fields. Which fields are available depends on your system (e.g., the SAML attributes of your ERP or the profile fields of your CMS). Therefore, you must adjust the source field names here:

exports.onExecutePostLogin = async (event, api) => {
  const ns = "https://k3-konfigurator.de/";
  // Nutzerprofil aus dem angebundenen System.
  // Passen Sie die Feldnamen (rechts) an das an, was Ihr System liefert:
  const src = event.user;

  api.idToken.setCustomClaim(ns + "pricelist", src.pricelist);
  api.idToken.setCustomClaim(ns + "dealer", src.dealer);
  api.idToken.setCustomClaim(ns + "contact", {
    phone: src.phone_number,
    company: src.company,
  });
};

What does my system provide?

You can see what is stored in event.user after a test login in Auth0 under User Management > Users > [User] (Raw JSON view) or in the log of your action. Use this information to determine the field names in the action.

What contact fields are available?

The following fields are allowed in the contact field: name, email, phone, address, city, zip, country, company, taxID, remark. All are optional.

Good to Know

• pricelist and dealer are the codes for the price list and the dealer, respectively (not the display name).
• For attributes, the keys are the variable keys of your configurator; color and width are just examples.
• After any change to the action or user data, the user must log in again so that a fresh token with the new values is loaded.

Security

The values from Auth0 are tamper-proof (signed token) and take precedence over values in the URL. If the merchant sets one price list and Auth0 sets another, the one from Auth0 applies.

Only without Web Components

Login via Auth0 works if the configurator runs as a separate page (link/iFrame)—not as an embedded Web Component, since Auth0 requires a redirect.