Custom Join form returns 419 error

I am working on a new project and wanted to take advantage of it to use Filament V3. I have created a Users section where I can create, edit and delete them. However I don't want to have a register form, so when I create a user an email is sent with a url to create the account. The url contains a token that expires after a period of minutes. Everything works great up to this point, I added a custom action button to resend the invitation in case it expires or the email address is changed. However I am having issues to create the Join form, which is just a SimplePage with the email address, password and confirmation password. I have checked how the Register page works and even checked the code of the Breezy plugin. I tried to replicate every single piece of code except for the parts that I need to change like the properties, the function to submit the form, etc., and every time I try to submit I get a 419 error. The CSRF token is there so it doesn't seem to be the issue. If I just create a Page with the filament-page command and seems to only create a Page for logged in users and couldn't find a way to make it work differently. In those kind of pages the form works great and don't get any 419 error. I am an experienced developer but never worked before with livewire nor filament. I usually work with InertiaJS and React. Could you please guide me on what could I be doing wrong?
Solution:
Hi! Thanks for your answer. That is correct I don't want people to freely register but do so via an invitation link received via email. At first I developed it like you said but I don't think that is really very secure as people is used to just log in with that password, save it in the browser, and forget about it. So if someone manages to get to his email account will have access to the platform, I prefer the user to create their own password. This has been a while ago so, but the way I managed to get it working was to add in the AdminPanelProvider:...
Jump to solution
4 Replies
Abel Cobreros
Abel CobrerosOP17mo ago
Ok, so some update about it. If I add "livewire/update" to the Csrf exception attribute in the middleware the form works. But I don't get it as the csrf token seems to be there. One the page loads I look at the response cookies and the XSRF-TOKEN is present, as soon as I click submit that particual cookie is missing and the 419 error shows up. Tried with Filament's login and reset password pages and everything works as expected and the cookie is there in the response as soon as I submit. What am I missing here? I tried to add @csrf also inside the form but still nothing. It must be some silly thing but can't find the solution anywhere.
awcodes
awcodes12mo ago
I don’t understand you don’t want user registration but you’re trying to implement a custom registration? Without Registration I would recommend forgetting about registration at all. When you create a new user on the backend, create it with a random password and send them a password reset email instead. And then even if it expires, they can always just initiate the forgot password flow themselves to reset it and gain access.
Solution
Abel Cobreros
Abel Cobreros11mo ago
Hi! Thanks for your answer. That is correct I don't want people to freely register but do so via an invitation link received via email. At first I developed it like you said but I don't think that is really very secure as people is used to just log in with that password, save it in the browser, and forget about it. So if someone manages to get to his email account will have access to the platform, I prefer the user to create their own password. This has been a while ago so, but the way I managed to get it working was to add in the AdminPanelProvider: use App\Http\Middleware\EncryptCookies; Instead of the one that comes by default (use Illuminate\Cookie\Middleware\EncryptCookies). That solved my 419 issue.
Tim van Heugten
Tim van Heugten11mo ago
Fyi, what @awcodes meant was not sending the password in plaintext, but using the password reset notification (probably adapted as an onboarding email) so that the user has to set a new password. This would still be a valid approach for your scenario (if other people read this)
Want results from more Discord servers?
Add your server