Thank you @davcon for the new login module! It's been fun testing this over the past few days on a new app.
Hey everyone,
I'm wondering where the sign-up page should live?
Would you add it as a child module and configure it as a setting within config/login.php, since sign-up should be scoped to the user level?
Or would you just create a new module?
Best practice for sign-up pages alongside the new multi-level login module?
2 days ago
2 days ago
#1
2 days ago
#2
Hello,
I would not put it in config as a child, because config is special.
I would have it a module. Easy to protect with security.
Dan
I would not put it in config as a child, because config is special.
I would have it a module. Easy to protect with security.
Dan
2 days ago
#3
Hi Dan
Thank you.
I wasn't exactly clear, as I didn't mean to throw it within the config folder. Instead, I was wondering if we should create a separate module called sign-up or a child module within the login module?
Then activate it in config/login.php for example, like this:
Jim
Thank you.
I wasn't exactly clear, as I didn't mean to throw it within the config folder. Instead, I was wondering if we should create a separate module called sign-up or a child module within the login module?
Then activate it in config/login.php for example, like this:
Jim
2 days ago
#4
I hear what you're saying. You've raised a good point.
Personally speaking, I think your join page can go anywhere you like. A separate module? A method within a module (like 'members')? It's up to you.
However, it's important that the sign up process handles passwords in precisely the same way as the login module. That being the case, there may be room for improvement. I have a few ideas but if you have any thoughts on how this could be clearer or better then I'd welcome your feedback.
Personally speaking, I think your join page can go anywhere you like. A separate module? A method within a module (like 'members')? It's up to you.
However, it's important that the sign up process handles passwords in precisely the same way as the login module. That being the case, there may be room for improvement. I have a few ideas but if you have any thoughts on how this could be clearer or better then I'd welcome your feedback.
1 days ago
#5
Hey David, I’m thinking something similar to the “Forgot Password” flow within the login module. Give me a couple of days, and I’ll see what I can come up with and submit it as a pull request.
Jim
Jim
1 days ago
#6
That could be cool.
Just a thought:
What if we had a child module (within the 'login' module) named 'password_handler'? In that child module we could store all the rules and procedures to do with handling of passwords. It would all be for the login module. However, by having the password handling isolated and within a child module we might be able to make it very easy to re-use for situations like sign-ups.
Would that work?
Just a thought:
What if we had a child module (within the 'login' module) named 'password_handler'? In that child module we could store all the rules and procedures to do with handling of passwords. It would all be for the login module. However, by having the password handling isolated and within a child module we might be able to make it very easy to re-use for situations like sign-ups.
Would that work?
18 hrs ago
#7
Yes I think that would work nicely
Dan
Dan
15 hrs ago
#8
Yes, good suggestion David.
I submitted the password-child-refactor pull request.
I've updated all login form links to use the custom route when one exists, rather than falling back to the default. This ensures consistency across the board.
On logout, I've changed the redirect pointed at the base URL rather than login page. Happy to revert that part if you'd prefer it scoped to the login form default or custom route.
Working on "join" tomorrow.
I submitted the password-child-refactor pull request.
I've updated all login form links to use the custom route when one exists, rather than falling back to the default. This ensures consistency across the board.
On logout, I've changed the redirect pointed at the base URL rather than login page. Happy to revert that part if you'd prefer it scoped to the login form default or custom route.
Working on "join" tomorrow.
12 hrs ago
#9
The foundations sound cool, but slow down, my friend!
All this custom routes shenanigans and redirecting to the BASE_URL upon logout may be the best thing ever ... but it feels like too much too soon.
The remit is simple. We just need an easy way to reuse the password-handling stuff. That's all.
You're already a contributor to this framework and your legendary status is assured. You'll know better than most that, in the framework game, you have to tread lightly. We don't want to upset people by doing too much too soon.
Just stick to solving the problem you rightly identified. No heroics. It'll be cool.
Anyway, I haven't seen your pull request yet. Was it for the Trongate Framework repo?
All this custom routes shenanigans and redirecting to the BASE_URL upon logout may be the best thing ever ... but it feels like too much too soon.
The remit is simple. We just need an easy way to reuse the password-handling stuff. That's all.
You're already a contributor to this framework and your legendary status is assured. You'll know better than most that, in the framework game, you have to tread lightly. We don't want to upset people by doing too much too soon.
Just stick to solving the problem you rightly identified. No heroics. It'll be cool.
Anyway, I haven't seen your pull request yet. Was it for the Trongate Framework repo?
9 hrs ago
#10
No problem. I changed my mind and didn't want to submit until I heard back. I'll revise and submit with just the password_handler child module and any related changes.