[9.0] Destroy authentication

[tabuna]

With the release of Laravel 8, the development team has released a new starter kit Jetstream.

It is a replacement for the laravel/ui package currently used by the platform. This is a major change for which, in fact, it was impossible to prepare in advance. New product releases are hidden and not shown until the release.

Some features began to compete with the official packages:

• Authorization / Password recovery and other pages began to differ
• Two-factor authentication
• Roles (Groups)

In fact, this will soon become mainstream and other options will not be competitive. I have no desire to go against the prevailing trend (I have no joy about this), so I see the current decision to release a major release, which completely removes authorization from the package.

In fact, we will completely lose the login pages, password recovery pages, the blocked page, two-factor authentication, and some other less noticeable things that I have been working on for a year.

This will make the login threshold higher as users won't get it out of the box. But the entire platform is built for an authorized user, so I suggest using a neutral authorization method via HTTP Basic Authentication.

To at least somehow ease the entry threshold, you can add a new page to the documentation, where it was reported that the user himself needs to choose a package for this.

As far as roles and teams are concerned, little time has passed to make a decision about any decision on this matter. Therefore, I propose to leave the system of roles and permissions.

If you have any suggestions, comments or want to help, please write here.

[RomainMazB]

Hi @tabuna , I've discovered Orchid few weeks ago. I've tested few other admin dashboard, and one of the reason I've chosen Orchid is the roles and permissions system. It was mandatory for my project.

My project is a browser game and I'm using the roles to manage some level of authorization: I have few admins, forum moderators and "game masters" (supercharged player with some tools to help other players).

Since the game is using laravel/ui, I'm never facing the Orchid login view though. When I read your post I said to my self "ok, that's fair for the authentication views, they're just a copy of laravel/ui", but the roles and permission are one of the main feature of Orchid and IMO it would be a huge mess to totally destroy them.

Maybe the good compromise would be to simplify them and just keep the roles synced with the new Jetstream package?

As an example in my game we could manage with only three roles:

• super-admin
• game-master
• moderator

With only that feature we could protect my Orchid screen using the hasRole method. Without the need of the fine tuned permissions.

EDIT: Ok I've dived into the Jetstream doc and found that roles and permissions are fully implemented in it, which wasn't the case in laravel/ui . So yes, I now agree the fact that is would be useless to keep and maintain it in Orchid... The new documentation should expose an example on how to use Jetstream roles/permissions with Orchid.

[tabuna]

Hey @RomainMazB. Removing roles and permissions is not currently considered. Only authorization and what is connected with it.

[RomainMazB]

Ok I've misread this part:

As far as roles and teams are concerned, little time has passed to make a decision about any decision on this matter. Therefore, I propose to leave the system of roles and permissions.

I was definitely not in my shoes yesterday!

If only the authorization is concerned, my though as I've said would be 'ok, I never use it anyway and if I want, I just need to create a Jetstream auth page and point to its controller and redirect to the Orchid Home'

But now I'm on the other side of the line: why would you keep the roles and permission if it's already done in Jetstream?

For your mindsafe, you could just leave the responsibility to maintain this part to the Laravel team, so you won't never see any issue about Role or Permission. Just put some examples in the documentation to let us know how to work with them in Orchid. I could write this part in the documentation for you ( but not in Russian, that's out my capabilities ^^' ).

I feel like Orchid Permissions is mostly the same as Jetstream Permissions purpose, and so do Roles.

[tabuna]

I read the Jetstream docs and I think it's more for the public part. As an example, organizations or groups within an organization on GitHub. Small quote:

Jetstream's team features allow each registered user to create and belong to multiple teams. By default, every registered user will belong to a "Personal" team. For example, if a user named "Sally Jones" creates a new account, they will be assigned to a team named Sally's Team. After registration, the user may rename this team or create additional teams.

Therefore, now it is very similar, but should not be a complete replacement. I will learn it soon.

Also, it is not included by default even in Jetstream, but at Orchid a very important access system, for example, to upload a file to the server. Many examples, such as filters use roles.

[tabuna]

I have new information.

This change will also affect resource publishing. Due to the fact that she relies entirely on https://laravel.com/docs/7.x/frontend#adding-presets

Example from the documentation:

use Laravel\Ui\UiCommand;

UiCommand::macro('nextjs', function (UiCommand $command) {
    // Scaffold your frontend...
});

This means that the commands: php artisan ui orchid and php artisan ui orchid-source will not work. This was added here https://github.com/orchidsoftware/platform/issues/915

As far as I understand, there is no alternative in jetstream for this.

[RomainMazB]

I've just tested with a fresh installation of Laravel 8 + Jetstream with the livewire frontend, the commands you said are ok.

But another stuff is the fact that the /dashboard uri is used by jetstream as default, Orchid must use another to not be in conflict with the jetstream dashboard

During my test I've ran into a tiny problem though, the assets compilation crashed due to a not found on frappe-charts.min.css. I've made a PR to fix it.

[tabuna]

I've just tested with a fresh installation of Laravel 8 + Jetstream with the livewire frontend, the commands you said are ok.

They are fine as long as there is a laravel/ui dependency. The removal of which we are discussing here.

But another stuff is the fact that the /dashboard uri is used by jetstream as default, Orchid must use another to not be in conflict with the jetstream dashboard

Thank you for paying attention to this. have to change this to admin

[RomainMazB]

I'm currently trying to make Orchid work with Jetstream (I definetely want the bests of both :) ). With the Jetstream Roles and Permissions.

If it's ok for you, I will edit this comment to list some conflictual/cloned stuff:

• The User migration and model stubs: both implements 2fa authentication

[tabuna]

I have made the following changes so far:

• Changed the default prefix to admin
• Removed dependency on laravel/ui
• Removed password recovery option
• Removed last login column
• Removed two-factor authentication feature
• Removed UI presets

Important.
Simple authorization and remembering remained in the package. Everyone at any moment can turn off this page.

[falur]

Думаю роли точно пока трогать смысла нет. Тут как много пакетов так и велосипедов, и наврятли все метнутся куда-то сразу по крайней мере.

С аутентификацией изначально виделся такой вариант более подходящим. Но сейчас из пакета это очень удобно работает. В jetsteam ещё не смотрел, но видится сделать так что можно использовать то что есть сейчас и попробовать подружить с джетстримом

[falur]

Вообще сейчас полистал его, ты уверен что он скоро станет стандартом? nova как-то не стал, а тут пошли похожим путём

[tabuna]

Вообще сейчас полистал его, ты уверен что он скоро станет стандартом? nova как-то не стал, а тут пошли похожим путём

Привет @falur. У Nova, Spark есть альтернативы и проектов которым нужен этот функционал меньше чем тем, кому требуется авторизация. Пакет laravel/ui они убивают, фактически на официальном уровне остался только laravel/fortify, для которого есть оболочка Jetstream, которую конечно можно будет поменять и надеюсь сообщество сделает такие же расширения с другими js/css фреймворками.

Думаю логичным шагом будет так же уйти от использования laravel/ui. И предложить выбирать это на вкус.

Обращаю внимание, что страница входа остаётся в пакете, просто больше не привязана к пакету laravel/ui. То есть фактически, в плане выбора или кастомных страниц входа/восстановления пароля ничего не меняется. Проблема заключается только, в том, 2fa может конфликтовать/конкурировать c официальным пакетом.

[grigoriy-ivanov]

Может быть следует сделать отдельный пакет? Например, orchid-fortify для возможности сохранить функционал прошлых версий для 2fa