This commit builds the exit node menu including the recommended exit
node, if available, as well as tailnet and mullvad exit nodes.
This does not yet update the menu based on changes in exit node outside
of the systray app, which will come later. This also does not include
the ability to run as an exit node.
Updates #1708
Change-Id: Ia101a4a3005adb9118051b3416f5a64a4a45987d
Signed-off-by: Will Norris <will@tailscale.com>
The new menu delay added to fix libdbusmenu systrays causes problems
with KDE. Given the state of wildly varying systray implementations, I
suspect we may need more desktop-specific hacks, so I'm setting this up
to accommodate that.
Updates #1708
Updates #14431
Change-Id: Ia101a4a3005adb9118051b3416f5a64a4a45987d
Signed-off-by: Will Norris <will@tailscale.com>
Bring UI closer to macOS and windows:
- split login and tailnet name over separate lines
- render profile picture (with very simple caching)
- use checkbox to indicate active profile. I've not found any desktops
that can't render checkboxes, so I'd like to explore other options
if needed.
Updates #1708
Change-Id: Ia101a4a3005adb9118051b3416f5a64a4a45987d
Signed-off-by: Will Norris <will@tailscale.com>
Some notification managers crop the application icon to a circle, so
ensure we have enough padding to account for that.
Updates #1708
Change-Id: Ia101a4a3005adb9118051b3416f5a64a4a45987d
Signed-off-by: Will Norris <will@tailscale.com>
This adds a systray app for linux, similar to the apps for macOS and
windows. There are already a number of community-developed systray apps,
but most of them are either long abandoned, are built for a specific
desktop environment, or simply wrap the tailscale CLI.
This uses fyne.io/systray (a fork of github.com/getlantern/systray)
which uses newer D-Bus specifications to render the tray icon and menu.
This results in a pretty broad support for modern desktop environments.
This initial commit lacks a number of features like profile switching,
device listing, and exit node selection. This is really focused on the
application structure, the interaction with LocalAPI, and some system
integration pieces like the app icon, notifications, and the clipboard.
Updates #1708
Signed-off-by: Will Norris <will@tailscale.com>
The inflight request tracker only starts recording a new bucket after
the first non-error request. Unfortunately, it's written in such a way
that ONLY successful requests are ever marked as being finished. Once a
bucket has had at least one successful request and begun to be tracked,
all subsequent error cases are never marked finished and always appear
as in-flight.
This change ensures that if a request is recorded has having been
started, we also mark it as finished at the end.
Updates tailscale/corp#19767
Signed-off-by: Will Norris <will@tailscale.com>
The gliderlabs/ssh license is actually already included in the standard
package listing. I'm not sure why I thought it wasn't.
Updates tailscale/corp#5780
This reverts commit 11dca08e93.
Signed-off-by: Will Norris <will@tailscale.com>
This package is included in the tempfork directory, rather than as a go
module dependency, so is not included in the normal package list.
Updates tailscale/corp#5780
Signed-off-by: Will Norris <will@tailscale.com>
Mostly inconsequential minor fixes for consistency. A couple of changes
to actual JSON examples, but all still very readable, so I think it's
fine.
Updates #cleanup
Signed-off-by: Will Norris <will@tailscale.com>
This was originally built for testing node expiration flows, but is also
useful for customers to force device re-auth without actually deleting
the device from the tailnet.
Updates tailscale/corp#18408
Signed-off-by: Will Norris <will@tailscale.com>
Instead of constructing the `ip:port` string ourselves, use
netip.AddrPortFrom which handles IPv6 correctly.
Updates #11164
Signed-off-by: Will Norris <will@tailscale.com>
add the curly-quotes eslint plugin (same that we use for the admin
panel), and fix existing straight quotes in the current web UI.
Updates #cleanup
Signed-off-by: Will Norris <will@tailscale.com>
The new read-only mode is only accessible when running `tailscale web`
by passing a new `-readonly` flag. This new mode is identical to the
existing login mode with two exceptions:
- the management client in tailscaled is not started (though if it is
already running, it is left alone)
- the client does not prompt the user to login or switch to the
management client. Instead, a message is shown instructing the user
to use other means to manage the device.
Updates #10979
Signed-off-by: Will Norris <will@tailscale.com>
gitops-pusher supports authenticating with an API key or OAuth
credentials (added in #7393). You shouldn't ever use both of those
together, so we error if both are set.
In tailscale/gitops-acl-action#24, OAuth support is being added to the
GitHub action. In that environment, both the TS_API_KEY and OAuth
variables will be set, even if they are empty values. This causes an
error in gitops-pusher which expects only one to be set.
Update gitops-pusher to check that only one set of environment variables
are non-empty, rather than just checking if they are set.
Updates #7393
Signed-off-by: Will Norris <will@tailscale.com>
When establishing connections to the ipnserver, we validate that the
local user is allowed to connect. If Tailscale is currently being
managed by a different user (primarily for multi-user Windows installs),
we don't allow the connection.
With the new device web UI, the inbound connection is coming from
tailscaled itself, which is often running as "NT AUTHORITY\SYSTEM".
In this case, we still want to allow the connection, even though it
doesn't match the user running the Tailscale GUI. The SYSTEM user has
full access to everything on the system anyway, so this doesn't escalate
privileges.
Eventually, we want the device web UI to run outside of the tailscaled
process, at which point this exception would probably not be needed.
Updates tailscale/corp#16393
Signed-off-by: Will Norris <will@tailscale.com>
The manage client always listens on http (non-secure) port 5252. If the
login client is loaded over https, then the connectivity check to `/ok`
will fail with a mixed-content error. Mixed-content enforcement is a
browser setting that we have no control over, so there's no way around
this.
In this case of the login client being loaded over https, we skip the
connectivity check entirely. We will always render the sign-in button,
though we don't know for sure if the user has connectivity, so we
provide some additional help text in case they have trouble signing in.
Updates hassio-addons/addon-tailscale#314
Signed-off-by: Will Norris <will@tailscale.com>
Use the helper method from the version package to detect that we are
running the macsys network extension. This method does the same check
for the HOME environment variable (which works fine in most cases) as
well as the name of the executable (which is needed for the web client).
Updates tailscale/corp#16393
Signed-off-by: Will Norris <will@tailscale.com>
This is simply an extra check to prevent hypothetical issues if a prefix
such as `--prefix="javascript:alert(1)"` was provided. This isn't
really necessary since the prefix is a configuration flag provided by
the device owner, not user input. But it does enforce that we are
always interpreting the provided value as a path relative to the root.
Fixes: tailscale/corp#16268
Signed-off-by: Will Norris <will@tailscale.com>
Add a new "Debug" card at the bottom of the details page. It's maybe
premature to add a separate card for this, since all it currently lists
is whether the device is using TUN mode and (for Synology) the DSM
version. But I think it may be helpful to add client connectivity data
(like shown on admin console machine page) as well as a bug report
button. Those can come soon after the 1.56 launch.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
Calculate and set the hash of the one inline script we have in
index.html. That script is unlikely to change, so hardcoding the hash
seems fine for now.
Updates #10261
Updates tailscale/corp#16266
Signed-off-by: Will Norris <will@tailscale.com>
When displaying the login client, we check for connectivity to the
management client by calling it's /ok handler. If that response is
non-200, then there is something wrong with the management client, so
don't render the login button.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
Previously, we were only breaking out of iframes when accessing the
login client over a local IP address (where viewerIdentity is not set).
We need to also handle the case where the user is accessing the login
client over the Tailscale IP, and similarly break out of the iframe when
logging into the management client.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
I seem to recall I needed this for things to work properly with the vite
dev server, but that doesn't seem to be the case anymore? Everything
seems to work fine without it. If we still have issues, we'll need to
look into using a nonce or integrity attribute.
Updates #10261Fixestailscale/corp#16266
Signed-off-by: Will Norris <will@tailscale.com>
When running on Home Assistant, use the X-Ingress-Path header to set the
URLPrefix that is passed to the frontend.
Also fix handling of errNotUsingTailscale in the auth handler
(previously it falling through to a later case and returning a 500).
Instead, it's just a terminal state with no auth needed.
Also disable SSH on Home Assistant, since it causes problems on startup
and doesn't make much sense anyway for that platform.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
Limit cookies to HTTP requests (not accessible from javascript).
Set SameSite to "Lax", which is similar to "Strict" but allows for
cookies to be included in requests that come from offsite links. This
will be necessary when we link to the web client from the admin console.
Updates #10261Fixestailscale/corp#16265
Signed-off-by: Will Norris <will@tailscale.com>
The client has changed a bit since we introduced the path prefix. It is
now used for two things:
- its original purpose, of ensuring that when the client is run in CGI
mode at arbitrary paths, then relative paths for assets continue to
work
- we also now pass the path to the frontend and use wouter to manage
routes for the various subpages of the client.
When the client is run behind a reverse proxy (as it is in Home
Assistant), it is common for the proxy to rewrite the request so that
the backend application doesn't see the path it's being served at. In
this case, we don't need to call enforcePrefix, since it's already
stripped before it reaches us. However, wouter (or react router
library) still sees the original path in the browser, and needs to know
what part of it is the prefix that needs to be stripped off.
We're handling this by now only calling enforcePrefix when run in CGI
mode. For Home Assistant, or any other platform that runs the client
behind a reverse proxy with a custom path, they will still need to pass
the `-prefix` flag to `tailscale web`, but we will only use it for route
handling in the frontend.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
Add left and right padding around entire client so that the cards don't
run into the side of the screen. Also tighten up vertical spacing in
couple of places.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
If the login client is inside an iframe, open the management client in a
new window, since it can't be loaded in the frame.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
If the currently selected exit node is offline, render the exit node
selector in red with an error message. Update exit nodes in the dropdown
to indicate if they are offline, and don't allow them to be selected.
This also updates some older color values to use the new colors.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
Use the packet filter rules to determine if any device is allowed to
connect on port 5252. This does not check whether a specific device can
connect (since we typically don't know the source device when this is
used). Nor does it specifically check for wide-open ACLs, which is
something we may provide a warning about in the future.
Update the login popover content to display information when the src
device is unable to connect to the dst device over its Tailscale IP. If
we know it's an ACL issue, mention that, otherwise list a couple of
things to check. In both cases, link to a placeholder URL to get more
information about web client connection issues.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
client/web: skip check mode for non-tailscale.com control servers
Only enforce check mode if the control server URL ends in
".tailscale.com". This allows the web client to be used with headscale
(or other) control servers while we work with the project to add check
mode support (tracked in juanfont/headscale#1623).
Updates #10261
Co-authored-by: Sonia Appasamy <sonia@tailscale.com>
Signed-off-by: Sonia Appasamy <sonia@tailscale.com>
Signed-off-by: Will Norris <will@tailscale.com>
This adds an expandable section of the login view to allow users to
specify an auth key and an alternate control URL.
Input and Collapsible components and accompanying styles were brought
over from the adminpanel.
Updates #10261
Signed-off-by: Will Norris <will@tailscale.com>
This creates a new /api/up endpoint which is exposed in the login
client, and is solely focused on logging in. Login has been removed from
the nodeUpdate endpoint.
This also adds support in the LoginClientView for a stopped node that
just needs to reconnect, but not necessarily reauthenticate. This
follows the same pattern in `tailscale up` of just setting the
WantRunning user pref.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
This `go get` action has been running very slowly, and I'm pretty sure
it's because we're building gocross on the first `./tool/go` run, and
because we've set `GOPROXY=direct`, it's going directly to GitHub to
fetch all of the gocross dependencies.
Updates #cleanup
Signed-off-by: Will Norris <will@tailscale.com>
I don't believe this has ever worked, since we didn't allow POST
requests in the login client. But previously, we were primarily using
the legacy client, so it didn't really matter. Now that we've removed
the legacy client, we have no way to login.
This fixes the login client, allowing it to login, but it still needs to
be refactored to expose a dedicated login method, without exposing all
the node update functionality.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
We currently disable the exit-node drop down selector when the user is
in read-only mode, but we missed disabling the "Disable" button also.
Previously, it would display an error when clicked.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
Now that 1.54 has released, and the new web client will be included in
1.56, we can remove the need for the node capability. This means that
all 1.55 unstable builds, and then eventually the 1.56 build, will work
without setting the node capability.
The web client still requires the "webclient" user pref, so this does
NOT mean that the web client will be on by default for all devices.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
This removes the dev/unstable build check for the --webclient flag on
`tailscale set`, so that it will be included in the next major stable
release (1.56)
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
return early if handler is nil. Go ahead and return the error from
handler, though in this case the caller isn't doing anything with it
(which has always been the case).
Updates #10177
Updates #10251
Signed-off-by: Will Norris <will@tailscale.com>
Tailscale serve maintains a set of listeners so that serve traffic from
the local device can be properly served when running in kernel
networking mode. #10177 refactored that logic so that it could be reused
by the internal web client as well. However, in my refactoring I missed
actually calling the serve handler to handle the traffic.
Updates #10177
Signed-off-by: Will Norris <will@tailscale.com>
Move Header component inside Router so that links are relative to the
router base URL.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
In production, the asset handler is receiving requests for pages like
/details, which results in a 404. Instead, if we know the requested file
does not exist, serve the main index page and let wouter route it
appropriately on the frontend.
Updates tailscale/corp/#14335
Signed-off-by: Will Norris <will@tailscale.com>
After logging in, the `?check=now` query string is still present if it
was passed. Reloading the page causes a new check mode to be triggered,
even though the user has an active session. Only trigger the automatic
check mode if the user is not already able to manage the device.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
This prevents a panic in some cases where WebClientShutdown is called
multiple times.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
The local web client has the same characteristic as tailscale serve, in
that it needs a local listener to allow for connections from the local
machine itself when running in kernel networking mode.
This change renames and adapts the existing serveListener to allow it to
be used by the web client as well.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
We render the readonly view in two situations:
- the client is in login mode, and the device is connected
- the client is in manage mode, but the user does not yet have a session
If the user is not authenticated, and they are not currently on the
Tailscale IP address, render a "Manage" button that will take them to
the Tailcale IP of the device and immediately start check mode.
Still to do is detecting if they have connectivity to the Tailscale IP,
and disabling the button if not.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
Don't return CSP headers in dev mode, since that includes a bunch of
extra things like the vite server.
Allow images from any source, which is needed to load user profile
images.
Allow 'unsafe-inline' for various inline scripts and style react uses.
We can eliminate this by using CSP nonce or hash values, but we'll need
to look into the best way to handle that. There appear to be several
react plugins for this, but I haven't evaluated any of them.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
After running `tailscale web`, only disable the user pref if it was not
already previously set.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
Require that requests to servers in manage mode are made to the
Tailscale IP (either ipv4 or ipv6) or quad-100. Also set various
security headers on those responses. These might be too restrictive,
but we can relax them as needed.
Allow requests to /ok (even in manage mode) with no checks. This will be
used for the connectivity check from a login client to see if the
management client is reachable.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
if the user pref and nodecap for the new web client are enabled, serve
the client over requests to 100.100.100.100. Today, that is just a
static page that lists the local Tailcale IP addresses.
For now, this will render the readonly full management client, with an
"access" button that sends the user through check mode. After
completing check mode, they will still be in the read-only view, since
they are not accessing the client over Tailscale.
Instead, quad100 should serve the lobby client that has a "manage"
button that will open the management client on the Tailscale IP (and
trigger check mode). That is something we'll fix in a subsequent PR in
the web client code itself.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
This completes the migration to setting up authentication state in the
client first before fetching any node data or rendering the client view.
Notable changes:
- `authorizeRequest` is now only enforced on `/api/*` calls (with the
exception of /api/auth, which is handled early because it's needed to
initially setup auth, particularly for synology)
- re-separate the App and WebClient components to ensure that auth is
completed before moving on
- refactor platform auth (synology and QNAP) to fit into this new
structure. Synology no longer returns redirect for auth, but returns
authResponse instructing the client to fetch a SynoToken
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
WebClientShutdown tries to acquire the b.mu lock, so run it in a go
routine so that it can finish shutdown after setPrefsLockedOnEntry is
finished. This is the same reason b.sshServer.Shutdown is run in a go
routine.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
When the /api/auth response indicates that synology auth is needed,
fetch the SynoToken and store it for future API calls. This doesn't yet
update the server-side code to set the new SynoAuth field.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
For now this is effectively a noop, since only the ManagementClientView
uses the auth data. That will change soon.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
instead of starting a separate server listening on a particular port,
use the TCPHandlerForDst method to intercept requests for the special
web client port (currently 5252, probably configurable later).
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
This is not currently exposed as a user-settable preference through
`tailscale up` or `tailscale set`. Instead, the preference is set when
turning the web client on and off via localapi. In a subsequent commit,
the pref will be used to automatically start the web client on startup
when appropriate.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
The branch name selector "*" doesn't match branches with a "/" in their
name. The vast majority of our PRs are against the main (or previously,
master) branch anyway, so this will have minimal impact. But in the rare
cases that we want to open a PR against a branch with a "/" in the name,
tests should still run.
```
gh pr list --limit 9999 --state all --json baseRefName | \
jq -cs '.[] | group_by(.baseRefName) |
map({ base: .[0].baseRefName, count: map(.baseRefName) | length}) |
sort_by(-.count) | .[]'
{"base":"main","count":4593}
{"base":"master","count":226}
{"base":"release-branch/1.48","count":4}
{"base":"josh-and-adrian-io_uring","count":3}
{"base":"release-branch/1.30","count":3}
{"base":"release-branch/1.32","count":3}
{"base":"release-branch/1.20","count":2}
{"base":"release-branch/1.26","count":2}
{"base":"release-branch/1.34","count":2}
{"base":"release-branch/1.38","count":2}
{"base":"Aadi/speedtest-tailscaled","count":1}
{"base":"josh/io_uring","count":1}
{"base":"maisem/hi","count":1}
{"base":"rel-144","count":1}
{"base":"release-branch/1.18","count":1}
{"base":"release-branch/1.2","count":1}
{"base":"release-branch/1.22","count":1}
{"base":"release-branch/1.24","count":1}
{"base":"release-branch/1.4","count":1}
{"base":"release-branch/1.46","count":1}
{"base":"release-branch/1.8","count":1}
{"base":"web-client-main","count":1}
```
Updates #cleanup
Signed-off-by: Will Norris <will@tailscale.com>
This will be returned from the upcoming control endpoints for doing web
client session authentication.
Updates tailscale/corp#14335
Signed-off-by: Will Norris <will@tailscale.com>
We already had a path on the web client server struct, but hadn't
plumbed it through to the CLI. Add that now and use it for Synology and
QNAP instead of hard-coding the path. (Adding flag for QNAP is
tailscale/tailscale-qpkg#112) This will allow supporting other
environments (like unraid) without additional changes to the client/web
package.
Also fix a small bug in unraid handling to only include the csrf token
on POST requests.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Instead of trying to use the user config dir, and then fail back to the
OS temp dir, just always use the temp dir. Also use a filename that is
less likely to cause collisions.
This addresses an issue on a test synology instance that was
mysteriously failing because there was a file at /tmp/tailscale. We
could still technically run into this issue if a
/tmp/tailscale-web-csrf.key file exists, but that seems far less likely.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This uses the new react-based web client for all builds, not just with
the --dev flag.
If the web client assets have not been built, the client will serve a
message that Tailscale was built without the web client, and link to
build instructions. Because we will include the web client in all of our
builds, this should only be seen by developers or users building from
source. (And eventually this will be replaced by attempting to download
needed assets as runtime.)
We do now checkin the build/index.html file, which serves the error
message when assets are unavailable. This will also eventually be used
to trigger in CI when new assets should be built and uploaded to a
well-known location.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Synology and QNAP both run the web client as a CGI script. The old web
client didn't care too much about requests paths, since there was only a
single GET and POST handler. The new client serves assets on different
paths, so now we need to care.
First, enforce that the CGI script is always accessed from its full
path, including a trailing slash (e.g. /cgi-bin/tailscale/index.cgi/).
Then, strip that prefix off before passing the request along to the main
serve handler. This allows for properly serving both static files and
the API handler in a CGI environment. Also add a CGIPath option to allow
other CGI environments to specify a custom path.
Finally, update vite and one "api/data" call to no longer assume that we
are always serving at the root path of "/".
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Add separate server methods for synology and qnap, and enforce
authentication and authorization checks before calling into the actual
serving handlers. This allows us to remove all of the auth logic from
those handlers, since all requests will already be authenticated by that
point.
Also simplify the Synology token redirect handler by using fetch.
Remove the SynologyUser from nodeData, since it was never used in the
frontend anyway.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This commit doesn't change any of the logic, but just organizes the code
a little to prepare for future changes.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Indicate to the web client when it is running in CGI mode, and if it is
then cache the csrf key between requests.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Under normal circumstances, you would typically want to keep the default
behavior of requiring secure cookies. In the case of the Tailscale web
client, we are regularly serving on localhost (where secure cookies
don't really matter), and/or we are behind a reverse proxy running on a
network appliance like a NAS or Home Assistant. In those cases, those
devices are regularly accessed over local IP addresses without https
configured, so would not work with secure cookies.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This ensures that `go mod vendor` includes these files, which are needed
for client builds run in corp.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
I thought this had something to do with Synology or QNAP support, since
they both have specific authentication logic. But it turns out this was
part of the original web client added in #1621, and then refactored as
part of #2093. But with how we handle logging in now, it's never
called.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
src/**/* was only grabbing files in subdirectories, but not in the src
directory itself.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
instead of embedding each file individually, embed them all into a
single embed filesystem. This is basically a noop for the current
frontend, but sets things up a little cleaner for the new frontend.
Also added an embed.FS for the source files needed to build the new
frontend. These files are not actually embedded into the binary (since
it is a blank identifier), but causes `go mod vendor` to copy them into
the vendor directory.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This builds the assets for the new web client as part of our release
process. The path to the web client source is specified by the
-web-client-root flag. This allows corp builds to first vendor the
tailscale.com module, and then build the web client assets in the vendor
directory.
The default value for the -web-client-root flag is empty, so no assets
are built by default.
This is an update of the previously reverted 0fb95ec
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This caused breakages on the build server:
synology/dsm7/x86_64: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
synology/dsm7/i686: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
synology/dsm7/armv8: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
...
Reverting while I investigate.
This reverts commit 0fb95ec07d.
Signed-off-by: Will Norris <will@tailscale.com>
This builds the assets for the new web client as part of our release
process. These assets will soon be embedded into the cmd/tailscale
binary, but are not actually done so yet.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Serving the web client on the tailscale interface, while useful for
remote management, is also inherently risky if ACLs are not configured
appropriately. Switch the example to listen only on localhost, which is
a much safer default. This is still a valuable example, since it still
demonstrates how to have a web client connected to a tsnet instance.
Updates #13775
Signed-off-by: Will Norris <will@tailscale.com>
This copies the existing go template frontend into very crude react
components that will be driven by a simple JSON api for fetching and
updating data. For now, this returns a static set of test data.
This just implements the simple existing UI, so I've put these all in a
"legacy" component, with the expectation that we will rebuild this with
more properly defined components, some pulled from corp.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
move the tailscale web client out of the cmd/tailscale/cli package, into
a new client/web package. The remaining cli/web.go file is still
responsible for parsing CLI flags and such, and then calls into
client/web. This will allow the web client to be hooked into from other
contexts (for example, from a tsnet server), and provide a dedicated
space to add more functionality to this client.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Refactor two shared functions used by the tailscale cli,
calcAdvertiseRoutes and licensesURL. These are used by the web client as
well as other tailscale subcommands. The web client is being moved out
of the cli package, so move these two functions to new locations.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
When using a custom http port like 8080, this was resulting in a
constructed hostname of `host.tailnet.ts.net:8080.tailnet.ts.net` when
looking up the serve handler. Instead, strip off the port before adding
the MagicDNS suffix.
Also use the actual hostname in `serve status` rather than the literal
string "host".
Fixes#8635
Signed-off-by: Will Norris <will@tailscale.com>