remove login and user model
schmunk42 opened this issue · comments
What steps will reproduce the problem?
Use this template and find out in a few months that the login has a serious security issue. I think we had that in yii2-app-basic and/or ...advanced.
Or forget to remove the current user/login code when installing a custom module.
What's expected?
Easy updating/patching in case of bugs or security issues, i.e. with composer.
Docs about how to install a user-management module, ie. yii2-usuario.
What do you get instead?
It's pretty hard to patch anything which comes from the template.
CC: @cebe
It's pretty hard to patch anything which comes from the template.
Why? Once you've installed the template it's yours.
Why? Once you've installed the template it's yours.
Because it's not a package which can be updated with composer and the login part contains way too much logic (100s of lines) in my opinion to be put into a template.
It makes it look easy, in the way it is now - but login/user-management/password-recovery/auth-tokens are a complex topic.
Personally I don't think there is too much logic in User / LoginForm. Maybe we could put some of the functions, e.g: validateAuthKey(), validatePassword, etc in a base framework model, but I don't think we should remove the models entirely.
Easy updating/patching in case of bugs or security issues, i.e. with composer
I want to notify that application templating approach is changing in 3.0.
Now this package is not a template for users to change but a dependency to be installed and easily updated with composer.
Actual application template for user to copy and change is yii-app-template and it has not a single PHP code file.
Unfortunately there is no good documentation about it.
But there is an article about this approach: https://hiqdev.com/pages/articles/app-organization
@hiqsol That's pretty cool looking, what's the state of https://github.com/yiisoft/yii-app-template, since it's released under the yiisoft namespace?
Will it be the new default template and the repo here "just" an example application?
Why is yii-app a requirement of the template?
I didn't really get your questions :)
yii-app-template is application template for users to copy and change. So it is actually "template".
yii-app is example of extendable application base for users to require in their applications to get some basic features.
So user application and yii-app can be developed separately and users can get updates to yii-app with composer.
yii-app and yii-app-template are completely functional and more or less finished and (I hope) not about to change a lot.
You can install it following installation instructions at https://github.com/yiisoft/yii-app-template
But the Yii 3.0 (all the packages) are now under heavy development.
You can see description of changes here https://github.com/yiisoft/core/blob/master/UPGRADE.md
I don't like the application nesting approach that much to be honest, IMHO those should be modules.
How about changing this repo to contain a very minimal web-module, you could then continue using it in yii-app-template - I think it's great that that has no PHP code.
And the yii-app-template could be designed to pick also other modules like api-module or cli-module, this relates to yiisoft/app-api#1
I don't like the application nesting approach that much to be honest, IMHO those should be modules.
And how do you distinguish yii-app is module or nested application? ;)
It's just how you call them!
What I'm trying to achieve is to make application really easy buildable from blocks (plugins or modules or other name). The simplest point of view is that we have the outermost package and it is the application. And everything else is module (plugin). But not all plugins are born to be equal ;)
yiisoft/core, yii-web, yii-console, yii-app, yiisoft/db all of them are modules (plugins) in that sense that they bring PHP classes and their configuration into the resulting application. But I would call them differently according to functions they perform:
yiisoft/core, yii-web, yii-console - framework
yiisoft/db, yiisoft/log - libraries
yiisoft/yii-app - application
And the yii-app-template could be designed to pick also other modules
It is already designed to pick any other modules. You require package (module/plugin) with composer and that's it - if it provides configuration it starts to do its job.
I really hope you read the article https://hiqdev.com/pages/articles/app-organization and look into mentioned examples.
And how do you distinguish yii-app is module or nested application? ;)
It's just how you call them!
Yes :) that's why I'd call it -module.
A module is a defined term in Yii you need to have a class (usually in Module.php) which extends from \yii\base\Module. Sure an Application also extends from Module that's what makes it "special". Why is there another term for it like plugin how does it differ?
yiisoft/core, yii-web, yii-console, yii-app, yiisoft/db all of them are modules (plugins) in that sense that they bring PHP classes and their configuration into the resulting application.
I don't think they are modules, since they have no class extending from Module as said above, they are extensions (often containing components) to the framework, distributed in composer packages.
yiisoft/core, yii-web, yii-console - framework
yiisoft/db, yiisoft/log - libraries
yiisoft/yii-app - application
I don't really see a difference between web, console and db, log - maybe you can elaborate? Why do the former have a prefix?
It is already designed to pick any other modules. You require package (module/plugin) with composer and that's it - if it provides configuration it starts to do its job.
I really hope you read the article https://hiqdev.com/pages/articles/app-organization and look into mentioned examples.
Yeah, I did read the article ;) Maybe it's just a naming thing.
My personal preference is also different when it comes to configuration, I really prefer a single file, since I don't find it easier to find things which are spread across multiple files, but that's not an issue here and should be up to the developer to choose which way he likes best.
@hiqsol Since you've removed the public folder from this repo as mentioned in https://github.com/yiisoft/yii-app-template/issues/1#issuecomment-414941648 - how is this now supposed to work as an app?
Good. Definitely we need naming agreements.
Why do the former have a prefix?
We have a little bit here about yii- prefix or not: https://github.com/yiisoft/docs/blob/master/packages.md
Why is there another term for it like plugin how does it differ?
Agree. Let's stick to "extension" term. Now extensions become pluggable but they are still extensions.
Then about module. Normal yii modules have they urls like /module/controller/action.
So yii-app is not a normal module at least in this sense. But it can be redone as plain module.
Actually I don't see a big difference. For me most important is 'legobility' ;)
Since you've removed the public folder from this repo as mentioned in yiisoft/yii-app-template#1 (comment) - how is this now supposed to work as an app?
yii-app is not supposed to work as app alone. But still it is functional, reusable and extendable app that is supposed to be installed as composer dependency.
Aren't also the general packages Yii dependent?
Can we get rid of the prefix yii- for all 3.0 packages?
yii-app is not supposed to work as app alone.
If this is a final decision, it should be reworked as a module and the repo name should be changed.
I really prefer a single file, since I don't find it easier to find things which are spread across multiple files
Yes. What's nice it is that you are completely free to work this way.
But you'll have to find and assemble configs manually.
Configs become really huge and unreadable.
And you don't receive config updates automatically.
Aren't also the general packages Yii dependent?
yiisoft/di is made from scratch and completely yii framework independable.
Also I've just redone yiisoft/rbac to be basically usable without yii framework.
It's still work to be done.
But we have clear idea: packages without yii- prefix can be reworked to be yii-independent and usable separately. And they will be reworked eventually.
Can we get rid of the prefix yii- for all 3.0 packages?
No.
yii- prefix explicitly marks packages as Yii extensions having yiisoft/core as their dependency.
Yii extensions are NOT usable without yii framework that's why yii-prefix.
But you'll have to find and assemble configs manually.
Yes, but there are less "surprises" why and especially where something is configured in a certain way.
Configs become really huge and unreadable.
But splitting them into several files is just left-pocket, right-pocket (but I had this topic with many developers :)) - I prefer one file, because it's way easier to search for a certain piece of config. I'll add feedback to the config-plugin about some of my findings.
And you don't receive config updates automatically.
We're doing this by building our apps upon Docker images which contain a full-featured app by-the-way, it's another topic, but could also be interesting for you, since we're trying to solve the same problem, see https://github.com/dmstr/phd5-template for an example.
yii- prefix explicitly marks packages as Yii extensions having yiisoft/core as their dependency.
Yii extensions are NOT usable without yii framework that's why yii-prefix.
Neat!
But splitting them into several files is just left-pocket, right-pocket (but I had this topic with many developers :)) - I prefer one file, because it's way easier to search for a certain piece of config.
config-plugin collects single file that you can inspect. And I plan to add debug config explaining where did every config value come from.
My main idea - let a thousand flowers bloom :)
Please do as you like. We'll be able to exchange our experience sometimes.
But everybody wins from separating configuration from the code and making it explicit.
If you prefer to assemble your configs manually now you can find all the configs in standart places - config folders.
I'll add feedback to the config-plugin about some of my findings.
I'll appreciate it very much!
I think this issue has enough.
And the discussion has floated far away from actual subject :)
Please open new issues.