Optional --auth flag on canvas:install

[prestontoor]

I use Laravel's auth system via Fortify to set up users with dashboard features. However, when they want to write a blog, they go to Canvas and login again which gets stored in the DB as a different username/password.

This is really clunky. Is there any way to allow canvas to link into Laravel's existing user platform or must there be a user profile/db for Laravel features and a user profile/db for blogging in Canvas?

[austintoddj]

Canvas used to use Laravel's auth system. It worked fine, except for the fact that things become really tied to the base Laravel user model at that point. If you use Laravel's system, and a developer assigns the PK on the user model to be userID instead of the default id, things break.

I agree that it's an extra step, but breaking things out like this allows the package to cater to a number of different users with various setups.

If you think of a solution that can cater to the 80/20, I'd love to hear it and perhaps work on getting it implemented. I'm intent on making the package better, and it's questions like this that push it ahead.

[prestontoor]

I'm very thankful for what you've made in Canvas. It's a great blogging system!

In regards to your answer, what about giving the option to use either the Laravel user authentication or use Canvas'? Perhaps two different repos or branches depending on how they're going to use it.

I think your blogging platform is great and would even pay a small one-time fee per project if it had the ability to work the way I described above.

[austintoddj]

That's highly encouraging, and I appreciate it.

Really interesting thought, similar to how Laravel Breeze or Jetstream allows optional flags like:

jetstream:install livewire
jetstream:install livewire --teams
jetstream:install inertia

Canvas might be able to adopt something like:

canvas:install --auth

I'll go ahead and mark this as an enhancement and see what I can do about coming up with a proof of concept for it.

[ReeceM]

Canvas used to use Laravel's auth system. It worked fine, except for the fact that things become really tied to the base Laravel user model at that point. If you use Laravel's system, and a developer assigns the PK on the user model to be userID instead of the default id, things break.

I agree that it's an extra step, but breaking things out like this allows the package to cater to a number of different users with various setups.

If you think of a solution that can cater to the 80/20, I'd love to hear it and perhaps work on getting it implemented. I'm intent on making the package better, and it's questions like this that push it ahead.

I know I used to use the Laravel auth system to link back to a separate app for users to log in with before the update. Admittedly was a bit confused at first :D. But figured it out.

Would there not a be a way to make it work similar to the Laravel auth system where you could redefine or extend the authentication system?

Similar to how you can add custom auth parts by overriding the interface's ?

So you could have a AuthProvider type of interface and define that in a Service Provider class, then you can define a new one that implements the concrete classes and methods as a user, maybe changing the Model to use.

You could then delegate where Canvas is checking for log in credentials, yet when not overridden can default to the original structure. That would probably make it not break for current users, and not noticeable for new users.

Below Added after above reply (https://github.com/austintoddj/canvas/issues/939#issuecomment-780823332)

I think the --auth part sounds practical, as that would allow you to have a set of stubs laid out and change it in a config section maybe.

You could maybe make an exportable migration for instance to create a table to hold roles for a user (and preferences), but could be edited if it doesn't fit the user's preferences. While not holding email information and such.

It could retain a foreign user_id could be string or BigInt. But then if the contract/interface style isn't used the user could define the primary linking key that links to roles and profile information and preferences.

The above is only stated based on the fact I dug through the code to figure out what was happening and saw how it worked to learn the auth system was different. Also knew some of the inner workings of the old one as I had extended the models and changed some features and table styles :)

[moseskamau338]

any progress on this?

[austintoddj]

@moseskamau338 No progress on this yet (just got back from a family vacation)

I'm still hashing out what this looks like functionally in the app. There's a discussion here that would be a perfect spot to drop any thoughts or ideas.