Deploy statuses

• 
• 
• 
• 

Frontend for access management

Settin up your dev-environment 🚀

Prerequisits

• To run or build the frontend, you'll need to download Node minimum v21 .
• Enable corepack on your machine and download yarn via corepack (don't download yarn globally, it will give you problems at some later point). Follow this guide to download yarn.

Running the Local-AT hybrid

Access management has a lot of dependencies, which can get tedious to work with when developing locally. If all you are working with is frontend-specific code (that is, the code found in this repo) then this hybrid solution will simplify your setup, allowing you to run the React application and the BFF (Backend For Frontend) locally, while using the access management backend and other dependencies that are deployed in an AT-environment.

However, it has an additional prerequisit as it will require you to log into your IDE (ex: Visual Studio) with a user that has access to the Keyvault used by test environment AT22.

To get these accesses on your ai-dev user, you need to be part of the following Azure team:

• Altinn-30-Authorization-Test-Developers

Make sure you have the neccecary accesses before proceeding with this setup alternative.

Step 1: Setting up the host file

In order to integrate the local code with AT22 in the most seamless way, using the login method, test data, and sdomain-specific tokens, we need to tell the computer when to divert from the the actual AT environment and instead use the localhoast port where our local BFF will be running from.

You can do this by adding following to the host file on your computer:

   # Subdomain for accessmanagement
   127.0.0.1 am.ui.at22.altinn.cloud

You can find this file in /private/etc/hosts on mac or in c:\Windows\System32\Drivers\etc\hosts on Windows

Remeber to save the host file before proceeding. You might need to flush the dns and clear all cashe in your browser for this change to be set into effect.

Windows:

   ipconfig /flushdns

OBS: Note that overwriting this path in the host file will make you unable to reach the true path from your computer, meaning you will not be able to use AT22 to test the currently deployed version of the frontend code. You will still be able to access the other AT environments.

Step 2: Run the BFF

Open Altinn.AccessManagement.UI.sln in Visual Studio (or another IDE).

• In Visual Studio, log in with your ai-dev email (the user that has the necessary accesses)
• Locate the Launch button
• Switch launch settings to the one named LocalDev (If not already chosen)
• Start the application by pressing the Launch button

A browser window will open on the BFFs swagger documentation, this means the launch was successfull.

OBS: These settings use https which requires a certificate to be uploaded or generated by your IDE (the latter is the easiest solution). This might make your browser flag the site as a possible risk the first time you attempt to navigate to it, but it will not stop you from accessing it.

Now that the BFF is running, you can move on to the react app.

Troubleshooting

If you encounter the error "Unhandled exception. System.IO.IOException: Failed to bind to address https://localhost:443", it usually means the application doesn't have the necessary permissions to use that port. This is because port 443 is a privileged port, typically requiring root access. However, running your entire application with elevated privileges (e.g., using sudo) is not recommended due to security risks. Instead, you can use a reverse proxy like nginx to handle port 443 and forward requests to your application running on a non-privileged port. This allows you to avoid running your app as root while still serving it on the standard HTTPS port.

1. Install nginx:

brew install nginx

2. Configure nginx:

Navigate to the nginx servers directory:

cd /opt/homebrew/etc/nginx/servers

Create a new configuration file (e.g., am_ui.conf) and add the following content:

server {
    listen 443 ssl;
    server_name localhost;

    ssl_certificate ssl/localhost.crt;
    ssl_certificate_key ssl/localhost.key;

    location / {
        proxy_pass https://localhost:5000;  
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. Create an SSL certificate:

Go back to the main nginx directory:

cd /opt/homebrew/etc/nginx/

Create an ssl directory:

mkdir ssl

Generate a self-signed certificate:

cd ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt

(You'll be prompted to enter information for the certificate. This information is not critical for local development, so feel free to fill in any values.)

4. Start nginx:

Start nginx

sudo nginx

Try running your app again. It should now work correctly on port 443, with nginx handling SSL encryption and forwarding requests to your application.

Step 3: Run the React application

Pull the newest version of this repo and navigate to its root

• Run yarn to install all neccecary dependencies
• Run yarn start to run the application

That's it!

Step 4: Accessing the solution

• Open you browser and go to https://info.at22.altinn.cloud/
• Log in using the regular Altinn login (with TestID)

You can now access the regular altinn features enabled in the environment. Once you navigate into a domain that belongs to this repo (am.ui.at22.altinn.cloud), the local code will run instead of the deployed code of this environment.

Happy coding!

Running with "The Mock"

The BFF provides us with the option of mocking away all external connections, instead fetching data from static files or generating it dynamically on-call. This can be usefull when testing out code only pertaining to the frontend or when developing functionality that lacks backend support.

The mock can be activated locally or in a specific environment by going to the relevant appsettings file and setting UseMockData to true. Be aware that this should NEVER be done for TT02 or PROD!

"GeneralSettings": {
  "FrontendBaseUrl": "https://am.ui.at22.altinn.cloud",
  "Hostname": "at22.altinn.cloud",
  "UseMockData": true
},

Fun fact: The static files used to run the mock is the same that is used for integration tests - meaning we get twice the usage out of the same data! ♻️

Login when in mock-mode

Since most of the mocked data is generated from static files, a lot of the functionality will only work for users that are part of the mocked data set. Here is a list of such users and their login details:

• 🍋 Sitrongul Medaljong - fNr: 20838198385

  • Covered in all static data with the same IDs as in at22
  • Is DAGL for Diskret Nær Tiger AS (310202398)

• 🦢 Intelligent Albatross - fNr: 19895199357

  • Used mostly to delegate things to from Sitrongul Medaljong (has the same IDs as in at22)
  • Is DAGL for Rakrygget Ung Tiger AS (313523497)

• 🎥 Livsglad Film - fNr: 21915399719

  • Used for automatically generated data (performance/worst case testing)
  • Partial data coverage (only new amUI)
  • Is DAGL for Sta Tom Tiger AS (313160300)

Build, Deploy and Release

Building and deploying 🚚

To create a distributable bundle, run yarn build. Environment variables set at build time will be baked into the bundle (e.g. VITE_DEFAULT_LOCALE=en yarn build). See the resulting dist/index.html. If the bundled files are to be served from a path other than the server root, you must pass the --base=/path/to/folder/ argument to yarn build.

Pull Request Labels

pr-labeler action is triggered for each pull request. Based on the branch name, this action adds a label to the pull request. The configuration for the labels can be found here.

Release

The application has a release every wednesday. scheduled-release action is triggered every wednesday 00.00. This action drafts a release, tags the latest package with the release version, f.ex this package has a release version v2023.1. The action drafts the release on different categories. The changes are categorized based on the pull request label. F.ex, A PR with a label bugfix is categorized under bug. The detailed release draft configuration can be found here The deploy in charge for the week, deploys the application to a specific environment(TT02/Prod) using the action deploy-to-environment. The drafted release is then reviewed manually and published by the deploy in charge.

Project organisation and code conventions 🧩

yarn commands 🧨

Run yarn to setup code.

Run yarn build to create a build file.

Run yarn test to run cypress tests in browser.

Run yarn coverage to see test coverage stats.

Run yarn lint to run lint checks

Run yarn format to format most of the codebase to set standard in config file

The main entry point is /src/main.jsx. You'll find React components under /src/components/.

The components can be placed 2 ways, either:

Repo structure

If the component's only reusable within a specific feature
features\
  featureName\
    components\
    - ComponentName.test.tsx (unit tests)
    - index.ts (public interface for the component)
    - style.css (if needed)

Or:

If the components are reusable and being used by other classes
components/
  ComponentName/
    - ComponentName.tsx
    - ComponentName.test.tsx (unit tests)
    - style.css (if needed)

Coding conventions 👮‍♀️

Naming convention on branches

Start with these names for your branch depending on what your branch includes.

• bugfix/
• chore/
• test/
• dependencies/
• documentation/
• feat/
• feat/<feature-name>/<issue-number>
• feat/general/<issue-number> (When it's not related to any specific feature. Can also just use feat/ by itself.)

ClassNames

Use PascalCase for component file names.

Code style

We use eslint, prettier, typescript, and automatically set up git hooks to enforce these on commits. To avoid confusion, it is recommended to set this up in your IDE.

Visual Studio Code

Install the eslint extension from the marketplace. Configure your IDE to run eslint --fix on save (prettier will also reformat your code when doing this).

WebStorm and IntelliJ IDEA

Configure your IDE to run eslint --fix on save (prettier will also reformat your code when doing this). It is also recommended to set up Prettier as the default formatter.

CSS

We use standard camelCase for classnames to enable linking of the stylesheets directly and improving simplicity in the process. We separate each Element and Modifier into separate names and use regular css (eks: .accordion.open) to access the combination.

Common problems in VS code

1. Sometimes it's needed to restart eslint for it to work properly. E.g. When switching branches, eslint hangs sometimes. To fix this problem in vs code: Do the hot key for workbench.action.quickNaviagtePreviousInFilePicker and run command 'restart eslint server' or restart vs code.
2. It's a common problem when writing reducers in rtk; invalid typescript-errors, prettier and lint-errors occurs. To fix this you could try to restart vs code or ignore the error.

Running Storybook with MSW Mock

You can define stories for components by adding a file with the *.stories.tsx extension.

Start Storybook: Use the following command to start Storybook:

yarn storybook

This project uses MSW (Mock Service Worker) to mock API requests in Storybook. The mock handlers are defined in .mock/handlers.js and the worker is set up in .mock/browser.js.

Documentation:

• For more information on writing stories, see the Storybook Docs.
• To learn about using MSW with Storybook, check out the MSW documentation.