directus-labs / agency-os

The open source operating system for digital agencies. Built with Directus and Nuxt.

Home Page:https://agencyos.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Magic link ends up with 401

Saddamus opened this issue · comments

Hello,
I have followed the guide for directus with agencyos template (docker) and Nuxt, all default (also build my own docker image basing on the guide). The frontend asks just for email (no password), but directus returns 401 and logging Invalid user credentials.
I guess, this magic link requires some additional config on directus or so (its not well explained).
I didn't forget to setup api token for Nuxt.
I have configured smtp variables, but i guess, the problem is somewhere in accepting this magic link auth method.

I've got a few updates coming soon. It's not actually a magic link login - that was just included as a sample of what you might to do, but it appears to be causing more confusion.

If you look at the LoginForm.vue you'll see its just using a preset login and password.

When you load the template instance from directus-template-cli you'll likely have to input new passwords for the pre-loaded users through the Directus instance in order to login to the portal.

Still not sure what shouild i do :) I just copied your git repo, filled env values and started dev instance. Do i need to change something on Nuxt or directus side to have password based auth on client portal ?

@Saddamus Create a password field for below the e-mail field. So your form in LoginForm.vue would look like this:

<form class="grid gap-4" @submit.prevent="attemptLogin">
	<UFormGroup label="Email" required>
		<UInput
			v-model="credentials.email"
			type="email"
			:disabled="loading"
			size="lg"
			name="email"
			label="Work Email"
			placeholder="john@example.com"
		/>
	</UFormGroup>
	<UFormGroup label="Password" required>
		<UInput
			v-model="credentials.password"
			type="password"
			:disabled="loading"
			size="lg"
			name="password"
			label="Account password"
			placeholder=""
		/>
	</UFormGroup>
	<UButton
		type="submit"
		:loading="loading"
		:disabled="!credentials.email"
		size="lg"
		label="Sign in"
		trailing-icon="material-symbols:arrow-forward"
		block
	/>
</form>

This way the credentials.password is editable.
The default password value is "password". Set here:

const credentials = reactive({
	email: 'ashley@example.com',
	password: 'password',
});

This is the password saved in Directus for this account. So when you sign in with this, this should work. Change the password or e-mail and you will get an error.

Good luck!

I've got a few updates coming soon. It's not actually a magic link login - that was just included as a sample of what you might to do, but it appears to be causing more confusion.

Agreed that this was confusing as with some other features that were "roughed-in" for demonstrations. If there are unfinished features (marked with @todo) they should probably only exist in a feature branch to be pulled into main/master later when they are completed or just provide more comments to understand what this stack is doing at that location.

Two-Cent Opinions: For most new users of this repo (and Directus as a whole) are probably digging through this repo to see "how" the stack works between Frontend+BFF (Nuxt) and Backend (Directus). This stack is so awesome but complex. Using separations into nuxt layers & nuxt modules overriding views and behavior is totally the right choice but the complexity probably warrants more detailed info to understand the setup as a whole. I know I was having difficulty realizing what behavior is hard-coded for show and what would need to be refactored to be dynamic. Logging on the Customer Portal was one of those spots. Stripe invoice payments on that portal is also not very clear if it's a PROD ready solution or just a demo of capabilities with hardcoding.

commented

I've worked on several Nuxt apps using Directus, but still the magic link here caused confusion on my side as well. Despite my experience, this specific issue required a deeper dive into the code to understand fully. A community-driven resource like a Wiki for this repository would be beneficial, as it could have saved time and provided clearer guidance.

#65 solves this confusion.