teleport/web
Cam Hutchison d3eed17856
build: Support arm64 and universal binaries for MacOS (#25460)
* build: Support ARM64 (cross)builds of fido2 et al

Add support for building/cross-building the fido2 libraries (cbor,
openssl and fido2), supporting ARM64 builds. This is done by adding the
appropriate flags to the library builds in `build-fido2-macos.sh` based
on the `C_ARCH` environment variable. If unset then the host
architecture is used. The `Makefile` defined `C_ARCH` based on the
`ARCH` variable, mapping it to an appropriate value for the C compiler.

Building the libraries should now be done through the new `build-fido2`
target, and getting the pkg-config path should be done with the
`print-fido2-pkg-path`. This is instead of calling the
`build-fido2-macos.sh` script directly as the `Makefile` takes care of
setting the `C_ARCH` environment variable appropriately.

* build: Add make target to install rust cross toolchain

Add the `rustup-set-target-toolchain` target to the Makefile to ensure
the right rust toolchain is installed for the version of Rust we use as
well as the target architecture we wish to generate code for, based on
the `ARCH` variable. This is intended to be used by CI jobs to ensure
they build with the correct toolchain.

* build: Support building MacOS packages for ARM64

Remove the restriction that allows only AMD64 packages to be built on
MacOS for the teleport and tsh packages. This is via the existing `-a`
flag to `build-package.sh` and a newly added `-a` flag to
`build-pkg-tsh.sh`.

This adds the architecture to the filename of the package to distinguish
the packages for different architectures.

Update the comments in the Makefile mentioning that `arch` is ignored.

build: add architecture to package names

* build: Build Teleport Connect with target architecture

When packaging Teleport Connect with electron-builder, pass an
architecture flag so that we can cross-build Teleport Connect. This will
allow us to build MacOS ARM64 binaries on the AMD64 runners.

Add the architecture to the `dmg` filename via the electron-builder
config, so that the filenames for different architectures don't clash.

* build: Copy Mac release artifacts to release directory

Copy the Mac release artifacts to a release artifact directory so that
the CI scripts do not have to. This makes it clearer what is and is not
a release artifact and puts the logic in the Makefile instead of the CI
yaml, so it can more easily be tested locally and to make it easier to
migrate to the next CI system.

This will also be useful for building universal binaries for Mac as the
CI system can put the architecture-specific binaries from a previous
workflow job into a common location.

We should look at copying all release artifacts for the other builds
(Linux tarballs and packages, etc) into this directory too. It may help
with unifying the GitHub Actions release workflows.

* build: Add MacOS universal builds

Add support for ARCH=universal on Darwin to produce universal (fat)
binaries from pre-built arm64 and amd64 binaries.

Packages (pkg) and disk images (dmg) for containing universal binaries
are named without an architecture in the filename, as that is the
current naming for the current AMD64-only releases. These universal ones
will replace those AMD64-only ones providing a single release artifact
working across architectures.

Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com>

* build: Do not clean before release-darwin

Remove the `clean` prerequisite from the `release-darwin-unsigned`
target as it is not needed when building on GitHub Actions, as it starts
with a fresh slate each run. We do not make releases manually so we
don't need to ensure a clean working directory there either.

Not doing a clean makes it easier to build a MacOS universal release as
it depends on the architecture-specific tarballs from a previous release
build. We would need to manually save the tarballs from the first
architecture release build as they would get deleted by the `clean` from
the second. So just stop cleaning as it is not needed.

---------

Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com>
2023-05-04 20:47:49 +00:00
..
.cloudbuild Bump golang.org/x/crypto in /web/.cloudbuild/scripts (#22360) 2023-02-28 17:53:05 +00:00
.github Add Dependency Review Action (#1437) 2022-12-15 17:24:07 +00:00
.storybook add themes to webui (#24507) 2023-04-14 21:45:23 +00:00
.vscode Teleterm Preview (beta) (#590) 2022-02-08 18:40:28 -05:00
@types Add license headers to web files that were missing it. (#21315) 2023-02-07 16:27:31 +00:00
packages build: Support arm64 and universal binaries for MacOS (#25460) 2023-05-04 20:47:49 +00:00
scripts Simplify and clean up Makefile (#62) 2020-04-07 00:50:07 -04:00
.dockerignore Move code to this repo 2019-09-12 19:37:15 -04:00
.drone.yml Disable drone for PR (#540) 2022-01-13 12:12:42 +11:00
.gitattributes Make linguist correctly classify JS protobuf files (#1300) 2022-10-26 06:50:25 +00:00
.gitignore Allow Webpack's HTTPS options to be set through environment variables (#1151) 2022-08-26 15:49:10 +00:00
.gitmodules Rename e submodule to webapps.e 2019-12-27 11:45:47 -05:00
README.md Fix vite development for desktop websocket endpoint (#23815) 2023-03-30 16:39:25 +00:00

Gravitational Web Applications and Packages

This directory contains the source code for:

The code is organized in terms of independent yarn packages which reside in the packages directory.

Getting Started with Teleport Web UI

You can make production builds locally or you can use Docker to do that.

Local Build

Make sure that you have yarn installed on your system since this monorepo uses the yarn package manager.

Then you need download and initialize these repository dependencies.

$ yarn install

To build the Teleport open source version

$ yarn build-ui-oss

The resulting output will be in the webassets folder.

Docker Build

To build the Teleport community version

$ make docker-ui

Getting Started with Teleport Connect

See README.md in packages/teleterm.

Development

Local HTTPS

To run vite for either Teleport or Teleport enterprise, you'll need to generate local self-signed certificates. The recommended way of doing this is via mkcert.

You can install mkcert via

brew install mkcert

After you've done this, run:

mkcert -install

This will generate a root CA on your machine and automatically trust it (you'll be prompted for your password).

Once you've generated a root CA, you'll need to generate a certificate for local usage.

Run the following from the web/ directory, replacing localhost if you're using a different hostname.

mkdir -p certs && mkcert -cert-file certs/server.crt -key-file certs/server.key localhost "*.localhost"

(Note: the certs/ directory in this repo is ignored by git, so you can place your certificate/keys in there without having to worry that they'll end up in a commit.)

Certificates in an alternative location

If you already have local certificates, you can set the environment variables:

  • VITE_HTTPS_CERT (required) - absolute path to the certificate
  • VITE_HTTPS_KEY (required) - absolute path to the key

You can set these in your ~/.zshrc, ~/.bashrc, etc.

export VITE_HTTPS_CERT=/Users/you/certs/server.crt
export VITE_HTTPS_KEY=/Users/you/certs/server.key

Web UI

To avoid having to install a dedicated Teleport cluster, you can use a local development server which can proxy network requests to an existing cluster.

For example, if https://example.com:3080 is the URL of your cluster then:

To start your local Teleport development server

PROXY_TARGET=example.com:3080 yarn start-teleport

If you're running a local cluster at https://localhost:3080, you can just run

yarn start-teleport

This service will serve your local javascript files and proxy network requests to the given target.

Keep in mind that you have to use a local user because social logins (google/github) are not supported by development server.

Unit-Tests

We use jest as our testing framework.

To run all jest unit-tests:

$ yarn run test

To run jest in watch-mode

$ yarn run tdd

Interactive Testing

We use storybook for our interactive testing. It allows us to browse our component library, view the different states of each component, and interactively develop and test components.

To start a storybook:

$ yarn run storybook

This command will open a new browser window with storybook in it. There you will see components from all packages so it makes it faster to work and iterate on shared functionality.

Setup Prettier on VSCode

  1. Install plugin: https://github.com/prettier/prettier-vscode
  2. Go to Command Palette: CMD/CTRL + SHIFT + P (or F1)
  3. Type open settings
  4. Select Open Settings (JSON)
  5. Include the below snippet and save:

    // Set the default
    "editor.formatOnSave": false,
    // absolute config path
    "prettier.configPath": ".prettierrc",
    // enable per-language
    "[html]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascript]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascriptreact]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode",
    },
    "[typescript]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescriptreact]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode",
    },
    "[json]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "vscode.json-language-features"
    },
    "[jsonc]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "vscode.json-language-features"
    },
    "[markdown]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode",
    },
    "editor.tabSize": 2,

MFA Development

When developing MFA sections of the codebase, you may need to configure the teleport.yaml of your target teleport cluster to accept hardware keys registered over the local development setup. Webauthn can get tempermental if you try to use localhost as your rp_id, but you can get around this by using https://nip.io/. For example, if you want to configure optional webauthn mfa, you can set up your auth service like so:

auth_service:
  authentication:
    type: local
    second_factor: optional
    webauthn:
      rp_id: proxy.127.0.0.1.nip.io

proxy_service:
  enabled: yes
  # setting public_addr is optional, useful if using different port e.g. 8080 instead of default 3080
  public_addr: ['proxy.127.0.0.1.nip.io']

Then start the dev server like PROXY_TARGET=https://proxy.127.0.0.1.nip.io:3080 yarn start-teleport and access it at https://proxy.127.0.0.1.nip.io:8080.

Adding Packages/Dependencies

We use Yarn Workspaces to manage dependencies.

The easiest way to add a package is to add a line to the workspace's package.json file and then run yarn install from the root of this repository.

Keep in mind that there should only be a single yarn.lock in this repository, here at the top level. If you add packages via yarn workspace <workspace-name> add <package-name>, it will create a packages/<package-name>/yarn.lock file, which should not be checked in.

Adding an Audit Event

When a new event is added to Teleport, the web UI has to be updated to display it correctly:

  1. Add a new entry to eventCodes.
  2. Add a new entry to RawEvents using the event you just created as the key. The fields should match the fields of the metadata fields on events.proto on Teleport repository.
  3. Add a new entry in Formatters to format the event on the events table. The format function will receive the event you added to RawEvents as parameter.
  4. Define an icon to the event on EventIconMap.
  5. Add an entry to the events array so it will show up on the AllEvents story
  6. Check fixture is rendered in storybook, then update snapshot for Audit.story.test.tsx using yarn test-update-snapshot.

You can see an example in this pr.