/api/auth/v1/* only works with `auth_ui`

[mrgnhnt96]

I am creating a CLI that requires auth, but I don't want the user to be forced to register in the web.

I would have thought that the components/auth_ui was only a helper to get a quick UI up to access the api/auth/* endpoints. I wouldn't have expected it to create the register endpoint.

Is this behavior expected? Is there anything I need to do to access the register endpoint without the UI?

[ignatz]

Welcome @mrgnhnt96 !

I am creating a CLI that requires auth, but I don't want the user to be forced to register in the web.

Sounds perfectly valid.

I would have thought that the components/auth_ui was only a helper to get a quick UI up to access the api/auth/* endpoints. I wouldn't have expected it to create the register endpoint.

We have the same expectation. The component is only meant as a drop-in UI.

W/o the component when I run:

curl --request POST --header "Content-Type: application/x-www-form-urlencoded" -d "email=test@test.com" -d "password=SuperSecret" -d "password_repeat=SuperSecret" http://localhost:4000/api/auth/v1/register

A registration email will be sent. In other words, the required POST endpoint at /api/auth/v1/register exists. Am I missing something?

In the spirit of minimizing back-and-forth, I could also see you wanting:

• to use a different encoding (e.g. JSON currently doesn't seem to be supported :/ - should be an easy fix)
• skip the verification flow entirely. The trail CLI currently has a trail user verify command but you may not want TB to send an email in the first place?

Thanks for bringing up the issue 🙏

EDIT: It seems perfectly reasonable that the trail CLI would also have a trail user add command.

[mrgnhnt96]

I am creating the CLI using dart, I cloned the trailbase repo and updated the dart client a bit. Once I formatted the response properly the request went through. The thing that was/is tripping me up is the response is returning a 404 (presumably because its trying to redirect?)

Here are the logs from trail run --dev

{"timestamp":"2025-12-17T14:36:29.594151+00:00","method":"Get","version":"Http11","host":"localhost:4000","uri":"/api/auth/v1/avatar/M6CVfrE5RuK_tbyzyzRprQ==","referer":"http://localhost:4000/_/admin/auth","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36","user":0,"client_ip":null,"status":404,"latency_ms":0.10175}
[2025-12-17T14:36:47.690980Z WARN  trailbase::email] No 'site_url' configured, falling back to 'http://localhost:4000'. This may be ok for development but will result in invalid auth links otherwise.
[2025-12-17T14:36:47.691037Z WARN  trailbase::email] No 'site_url' configured, falling back to sender 'noreply@localhost'. This may be ok for development environments but otherwise will result in your emails being filtered.
{"timestamp":"2025-12-17T14:36:47.708193+00:00","method":"Post","version":"Http11","host":"localhost:4000","uri":"/api/auth/v1/register?email=morgan5%40email.com&password=Password1%21&password_repeat=Password1%21","referer":"","user_agent":"Dart/3.10 (dart:io)","user":0,"client_ip":null,"status":303,"latency_ms":37.994709}
{"timestamp":"2025-12-17T14:36:47.709030+00:00","method":"Get","version":"Http11","host":"localhost:4000","uri":"/_/auth/login?alert=Registered%20morgan5@email.com.%20Email%20verification%20is%20needed%20before%20sign%20in.%20Check%20your%20inbox.","referer":"","user_agent":"Dart/3.10 (dart:io)","user":0,"client_ip":null,"status":404,"latency_ms":0.010625}
[2025-12-17T14:37:17.000969Z DEBUG trailbase::scheduler] alive
{"timestamp":"2025-12-17T14:37:26.055086+00:00","method":"Get","version":"Http11","host":"localhost:4000","uri":"/api/_admin/user?limit=20","referer":"http://localhost:4000/_/admin/auth","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36","user":230502705265178936295951518295882309683,"client_ip":null,"status":200,"latency_ms":1.081167}

to use a different encoding

Yes please! JSON would be preferred

skip the verification flow entirely

This would be nice enhancement. Especially during the beginning where I wanna get a POC out

Thank you for the quick response!

[mrgnhnt96]

Here is my working branch for the dart client: https://github.com/mrgnhnt96/trailbase/tree/mrgnhnt/dart-client

[ignatz]

The thing that was/is tripping me up is the response is returning a 404 (presumably because its trying to redirect?

That's very much the case 👍 . You can also see the redirect (303) in the logs.

There's probably two points here:

• The dart cliient probably shouldn't follow redirects
• The server should only redirect when the auth ui is installed

Yes please! JSON would be preferred

Will look into it 👍

This would be nice enhancement. Especially during the beginning where I wanna get a POC out

Are the trail binary and the CLI always running on the same machine? I'm asking because there's a big difference in the CLI having super-powers when you already have access to the server anyway vs giving super-powers through the API.

In other words, I'd be very open to add a new CLI command, which you could call in case you're running on the same machine. Otherwise, I'm not sure how to best go about it.

Here is my working branch for the dart client: https://github.com/mrgnhnt96/trailbase/tree/mrgnhnt/dart-client

I had a look at 6b1c636, with the code broken out it's very hard to see if anything changed.

[mrgnhnt96]

There's probably two points here:

The dart cliient probably shouldn't follow redirects
The server should only redirect when the auth ui is installed

That sounds accurate to me

Are the trail binary and the CLI always running on the same machine? I'm asking because there's a big difference in the CLI having super-powers when you already have access to the server anyway vs giving super-powers through the API.

In other words, I'd be very open to add a new CLI command, which you could call in case you're running on the same machine. Otherwise, I'm not sure how to best go about it.

They are not, but I think that it would be fair to assume that some web interface is needed to go through the whole verification flow. For now, I just wanna register a user and log them in

I had a look at 6b1c636, with the code broken out it's very hard to see if anything changed

Sorry about that, was trying to get organized a bit, take a look at mrgnhnt96/trailbase@main...mrgnhnt/dart-client, specifically at client/dart/lib/src/client.dart. All the other classes in different files were only extracted, no changes were made there

[ignatz]

They are not, but I think that it would be fair to assume that some web interface is needed to go through the whole verification flow. For now, I just wanna register a user and log them in

IIUC, you're ok with the state as is. If so, I'd leave it as is. I also added an "trail user add" command in the dev branch, in case that aids your bootstrapping in a dev environment.

Sorry about that, was trying to get organized a bit, take a look at mrgnhnt96/trailbase@main...mrgnhnt/dart-client, specifically at client/dart/lib/src/client.dart.

It's getting a bit late here but I'll take a look tomorrow 👍

[ignatz]

Sorry about that, was trying to get organized a bit, take a look at mrgnhnt96/trailbase@main...mrgnhnt/dart-client, specifically at client/dart/lib/src/client.dart.

Thanks 🙏 - ad hoc review:

• Adding a register method seems reasonable. The repeated password thing is probably more for UIs, specifically when using plain HTML forms.
• register endpoint now accepts JSON
• Instead of setTokens could you re-construct the client?
  • I'm not strictly opposed, mostly just trying to understand the use-case. Not that tokens will expire, so even with this function you'd have to re-login occasionally. It may just be simpler to always use login 🤷‍♀️

For all the more cosmetic changes, we can discuss them I would just prefer to not bundle them with the more structural changes.

[mrgnhnt96]

For all the more cosmetic changes, we can discuss them I would just prefer to not bundle them with the more structural changes.

For sure, I would have split them up into different PRs 👍

Instead of setTokens could you re-construct the client?

I am following a singleton/dependency injection pattern. So the single instance is shared across the project, because of this there isn't a real easy way to rebuild the client and replace the client. By exposing the tokens/creating a method to update them, it allows me to update and keep the same instance

The repeated password thing is probably more for UIs, specifically when using plain HTML forms.

I can take it out 👍

[ignatz]

I am following a singleton/dependency injection pattern. So the single instance is shared across the project, because of this there isn't a real easy way to rebuild the client and replace the client. By exposing the tokens/creating a method to update them, it allows me to update and keep the same instance.

Java enterprise patterns have finally reached Dart 😅. Jokes aside, you can always inject a client builder/factory. (if you're using something like riverpod, haven't used v3 but you used to be able to parametrize too)

[mrgnhnt96]

If it came down to that, I could 😊 It's just a bit more convenient to have the method there