Skip to main content

Wing Console Sign In

  • Author(s): @ainvoner
  • Submission Date: 2024-01-15
  • Stage: Proposal
  • Stage Date: 2024-01-15

This document describes the Wing Console Sign In process and rationale.

Background​

As we seek to be able to understand how wing is used, it has become increasingly important to establish a more direct and meaningful connection with our users. One of the ways to achieve this is by implementing a sign-in flow within the Wing Console application.

Requirements​

New users of Wing Console will be required to sign in with their GitHub account before having access to the Wing Console application.

Another requirement is to have only one user entity in Wing. This means that a user in Wing Console is also a user in Wing Cloud and vice versa.

User Experience​

New Users​

New users that will wing it will see a sign in dialog blocking the Wing Console UI. The rationale behind this decision is that we want to show the user a teaser of Wing Console while asking them to sign in.

Once users will be signed in with their GitHub account they will be able to use Wing Console.

EULA (End User License Agreement) for new users​

The license agreement should be added to the bottom of the sign in screen:

"By using the Wing Console you agree to these terms and conditions"

The current EULA should be updated since we would like to contact our users via email

Signed In Users​

Signed in users to Wing Console will not need to sign in again. They will be able to use Wing Console as usual.

Offline​

If the user is offline (no internet connection) they will be able to use Wing Console as usual without the need to sign in.

Support of multiple users on the same machine​

There would be no support for multiple users on the same machine.

Logging out​

There is no support for logging out. The user will need to delete the signedIn boolean from their machine.

User identity for Analytics​

Events generated by signed in users will include the user's GitHub account email as an integral part of their user identity. In contrast, Wing CLI users are initially anonymous, and all analytics events originating from the CLI are sent anonymously with a unique identifier. However, when a user signs in to Wing Console, the unique identifier associated with CLI analytics events will be associated with the signed in user's identity, allowing us to link CLI analytics data to specific user accounts.

Technical details​

Since we would like to have a single user entity in Wing, the process of signing in to Wing Console will use the same authentication mechanism as Wing Cloud. In fact, the user will actually be signing in to Wing Cloud and be redirected back to Wing Console without noticing.

In order to make sure a signed in user won't need to sign in again, we will save a signedIn boolean somewhere in the user's machine. We don't need to store more information than that because the analytics engine will save the user ID and the user's email.

In depth technical details: sign in flow​

Upon opening Wing Console, the user will be redirected to the Wing Cloud sign in page (in OAuth fashion). The redirection URL will include the anonymous analytics ID that is stored in the Wing Console App package.

After signing in to Wing Cloud, the user will be redirected back to the Wing Console. The redirection will not include any information at all, so the user's data will be safe. The Wing Cloud server will link the anonymous analytics ID with the user's ID and email, using the following code snippet:

import { Analytics } from "@segment/analytics-node";
analytics.identify({
  // The Wing Console App anonymous ID.
  anonymousId: "48d213bb-95c3-4f8d-af97-86b2b404dcfe",
  // The Wing Cloud user data.
  userId: "user_123",
  traits: {
    github: "johndoe",
    email: "johndoe@gmail.com",
  },
});

Possible Next Steps​

Add value for the user in exchange for signin up. Things which could be considered:

  • Deploy to wing.cloud directly from the console. This could upload the working directory to a Bucket from which wing.cloud could deploy. The deployment status and the url would be shown in the local console
  • Offer a solution similar to ngrok, to make the locally running instance available for remote services (e.g. webhooks) or users (e.g. demo purposes)
  • Host the Console in Wing Cloud. While doing so, we could provide the ngrok-like functionality out of the box

Support additional sign in providers (like google, etc.).