|
| 1 | +import Availability from '@components/Availability'; |
| 2 | +import TabItem from '@theme/TabItem'; |
| 3 | +import Tabs from '@theme/Tabs'; |
| 4 | + |
| 5 | +# Set up a local tunnel for custom UI development |
| 6 | + |
| 7 | +<Availability cloud oss={{ major: 1, minor: 20 }} /> |
| 8 | + |
| 9 | +For Logto Cloud users, We've made it easy to let you "Bring your own UI" to Logto. Cloud users can now upload a zip file containing the custom UI assets in Logto Console -> Sign-in experience -> Custom UI. (Check out the [Bring your UI](/docs/recipes/customize-sie/bring-your-ui) page for more details.) |
| 10 | + |
| 11 | +However, when developing such custom UI pages, users want to test and debug the code locally, before uploading to Logto Cloud. This CLI command helps you set up a local tunnel and connect the following 3 entities together: |
| 12 | +your Logto cloud auth endpoint, your application, and your custom sign-in UI. |
| 13 | + |
| 14 | +## Why do I need this? |
| 15 | + |
| 16 | +By default, when you click the "sign-in" button in your application, you will be navigated to the sign-in page configured at Logto endpoint. A successful sign-in flow can be illustrated as follows: |
| 17 | + |
| 18 | +```mermaid |
| 19 | +sequenceDiagram |
| 20 | + box Local machine |
| 21 | + participant A as Your application |
| 22 | + end |
| 23 | + box Logto Cloud |
| 24 | + participant B as Logto Cloud auth endpoint |
| 25 | + participant C as Logto sign-in page |
| 26 | + end |
| 27 | + A ->> B: User initiates "sign-in" action and request auth |
| 28 | + B -->> A: Return auth response and tell the client<br/>to redirect to the Logto sign-in page |
| 29 | + A ->> C: Redirect to the Logto sign-in page |
| 30 | + C ->> B: Submit the sign-in form and<br/>request experience API to authenticate |
| 31 | + B -->> C: Respond the sign-in request and<br/>tell the client to redirect to your application |
| 32 | + C -->> A: Redirect to your application |
| 33 | + A --> A: Handle the sign-in callback and<br/>the user is now authenticated |
| 34 | +``` |
| 35 | + |
| 36 | +But now since you are developing your own custom sign-in UI, you need a way to navigate to the custom sign-in UI pages running on your local machine instead. |
| 37 | +This requires a local tunnel service to intercept the outgoing requests from your application and redirect them to your custom sign-in UI pages. |
| 38 | + |
| 39 | +Additionally, you need to interact with Logto's experience API to authenticate users and manage sessions. |
| 40 | +This service will also help forward these experience API requests to Logto Cloud in order to avoid CORS issues. |
| 41 | + |
| 42 | +The sequence diagram below illustrates how a successful "sign-in" flow works with your custom UI and the tunnel service in place: |
| 43 | + |
| 44 | +```mermaid |
| 45 | +sequenceDiagram |
| 46 | + box Local machine |
| 47 | + participant A as Your application |
| 48 | + participant B as Your custom sign-in UI |
| 49 | + participant C as Tunnel |
| 50 | + end |
| 51 | + box Logto Cloud |
| 52 | + participant D as Logto Cloud auth endpoint |
| 53 | + participant E as Logto sign-in page |
| 54 | + end |
| 55 | + A ->> C: User initiates "sign-in" action and request auth |
| 56 | + C ->> D: Forward auth request to Logto Cloud endpoint |
| 57 | + D -->> C: Return auth response and tell the client<br/>to redirect to the Logto sign-in page |
| 58 | + C ->> B: Intercept the redirect and<br/>redirect to your custom sign-in page |
| 59 | + B ->> C: Submit the sign-in form and<br/>request experience API to authenticate |
| 60 | + C ->> D: Forward the experience API requests to Logto Cloud |
| 61 | + D -->> C: Authenticate sign-in request and<br/>tell the client to redirect to your application |
| 62 | + C -->> A: Redirect to your application |
| 63 | + A --> A: Handle the sign-in callback and<br/>the user is now authenticated |
| 64 | +``` |
| 65 | + |
| 66 | +With the tunnel service in place, you can now develop and test your custom sign-in UI locally, without needing to upload the assets to Logto Cloud every time you make a change. |
| 67 | + |
| 68 | +## Instructions |
| 69 | + |
| 70 | +### Step 1: Execute the command |
| 71 | + |
| 72 | +Assuming your Cloud tenant ID is `foobar`, and you have a custom sign-in page running on your local dev server at `http://localhost:4000`, then you can execute the command this way: |
| 73 | + |
| 74 | +<Tabs groupId="cmd"> |
| 75 | + |
| 76 | + <TabItem value="cli" label="CLI"> |
| 77 | + |
| 78 | +```bash |
| 79 | +logto tunnel -p 9000 --experience-uri http://localhost:4000/ --endpoint https://foobar.logto.app/ |
| 80 | +``` |
| 81 | + |
| 82 | + </TabItem> |
| 83 | + <TabItem value="npx" label="npx"> |
| 84 | + |
| 85 | +```bash |
| 86 | +npx @logto/cli tunnel -p 9000 --experience-uri http://localhost:4000/ --endpoint https://foobar.logto.app/ |
| 87 | +``` |
| 88 | + |
| 89 | + </TabItem> |
| 90 | + |
| 91 | +</Tabs> |
| 92 | + |
| 93 | +It also works if you have custom domain configured in Logto: |
| 94 | + |
| 95 | +<Tabs groupId="cmd"> |
| 96 | + |
| 97 | + <TabItem value="cli" label="CLI"> |
| 98 | + |
| 99 | +```bash |
| 100 | +logto tunnel -p 9000 --experience-uri http://localhost:4000/ --endpoint https://your.custom.domain/ |
| 101 | +``` |
| 102 | + |
| 103 | + </TabItem> |
| 104 | + <TabItem value="npx" label="npx"> |
| 105 | + |
| 106 | +```bash |
| 107 | +npx @logto/cli tunnel -p 9000 --experience-uri http://localhost:4000/ --endpoint https://your.custom.domain/ |
| 108 | +``` |
| 109 | + |
| 110 | + </TabItem> |
| 111 | + |
| 112 | +</Tabs> |
| 113 | + |
| 114 | +Alternatively, the command also supports static html assets without needing to run it first on a dev server. Just make sure there's a `index.html` in the path you specified. |
| 115 | + |
| 116 | +<Tabs groupId="cmd"> |
| 117 | + |
| 118 | + <TabItem value="cli" label="CLI"> |
| 119 | + |
| 120 | +```bash |
| 121 | +logto tunnel -p 9000 --experience-path /path/to/your/static/files --endpoint https://foobar.logto.app/ |
| 122 | +``` |
| 123 | + |
| 124 | + </TabItem> |
| 125 | + <TabItem value="npx" label="npx"> |
| 126 | + |
| 127 | +```bash |
| 128 | +npx @logto/cli tunnel -p 9000 --experience-path /path/to/your/static/files --endpoint https://foobar.logto.app/ |
| 129 | +``` |
| 130 | + |
| 131 | + </TabItem> |
| 132 | + |
| 133 | +</Tabs> |
| 134 | + |
| 135 | +### Step 2: Update endpoint URI in your application |
| 136 | + |
| 137 | +Finally, run your application and set its Logto endpoint to the tunnel service address `http://localhost:9000/` instead. |
| 138 | + |
| 139 | +Let's take a React application as an example: |
| 140 | + |
| 141 | +```tsx title=App.tsx |
| 142 | +import { LogtoProvider, LogtoConfig } from '@logto/react'; |
| 143 | + |
| 144 | +const config: LogtoConfig = { |
| 145 | + // endpoint: 'https://foobar.logto.app/', // original Logto Cloud endpoint |
| 146 | + endpoint: 'http://localhost:9000/', // tunnel service address |
| 147 | + appId: '<your-application-id>', |
| 148 | +}; |
| 149 | + |
| 150 | +const App = () => ( |
| 151 | + <LogtoProvider config={config}> |
| 152 | + <YourAppContent /> |
| 153 | + </LogtoProvider> |
| 154 | +); |
| 155 | +``` |
| 156 | + |
| 157 | +If all set up correctly, when you click the "sign-in" button in your application, you should be navigated to your custom sign-in page instead of Logto's built-in UI, along with valid session (cookies) that allows you to further interact with Logto experience API. |
| 158 | + |
| 159 | +Happy coding! |
0 commit comments