Entities,
Controllers,
Routes /passwords/forgot changes to /passwords/recover
Everything.

Forgot is a verb in the past,
Recover is a verb in the present.

app/controllers/hello/concerns/forgot_password_on_success.rb should be reviewed so...

1. it is easier to understand
2. it comes with a clear nice default strategy

Draw specs for hello_keep_current_url_on_session! on Stateless requests.

Tip: move the code from
lib/hello/railsy/controller/sudo_mode_concern.rb
to
hello/lib/hello/manager/*

switch_users_controller.rb#L20 messages should be translatable.

This can be easily done by creating a class inheriting from AbstractEntity such as unlink_access_entity.rb and encapsulating the messages as demonstrated here.

The expected translations will be at hello.en.yml.

Don't worry about the details, the specs will break indicating what your next steps should be 😄

Please tell us what you think of controllers/sudo_mode_concern.rb, it's implementation, relevancy or anything else you might think of it.

Mounting the gem on an app would be necessary to get a better understanding of what it does.

But please, speak your mind 😄

Rename UpdateMyUserEntity to UpdateCurrentUserEntity or CurrentUserEntity.
the current name no longer makes sense.

initializers/hello.rb should include a configuration line such as

config.force_ssl = false

defaulted to either true or false, whichever makes more sense for a default implementation.

Draw specs for sudo mode when requests are not type GET.

Explaining.

A good example of Sudo Mode in use is the feature to cancel your account.
It is not safe to allow a user to cancel their account if you are not sure the user who claims to be.
So you ask for their password again before you allow them to use the feature. feature description and bdd/rspec/capybara sources here

Currently Sudo Mode works as the following:

a method sudo_mode invoked from the controller will redirect to "/hello/sudo_mode" if sudo_mode? returns false. This can be observed here. And it is actually done by rendering, not redirection. sources here

The explanation above you render you a form. Submitting this form will lead you to this action sources here. which will ensure your password and update your current_access_token, and from now on the controller method sudo_mode? will return true instead of false.

The updating of current_access_token is done using a datetime field as explained in these sources, allowing the user to access controller actions restricted by the sudo mode for a limited time. This limited time is configurable in the hello initializer sources here

What are we looking for?

Currently the Sudo Mode feature only allows you to deny the user access to the forms which will submit the actions that will actually perform sensitive and restricted changes.
It works very well for hiding sensitive information that you don't want shown to the user unless they validate they are who they claim to be.

However, here is an even better feature in some cases.
We will use the example of "add an admin to a group" for this pair of scenario.

Scenario 1, success
Given I am on the members page for group "Vegans of The World"
When I attempt to turn "John" into an admin;
And I fill in the correct password on the Sudo Mode Form
Then I should see "John was turned to an admin"

Scenario 2
Given I am on the members page for group "Vegans of The World"
When I attempt to turn "John" into an admin;
And I fill in the incorrect password on the Sudo Mode Form
Then I should see "Data on your failed attempt has been emailed to the owner of this account"

Conclusion

This feature should

1. intercept non-GET actions,
2. store the information on the request,
3. authenticate the user again by their password
   4.1. use the stored information to execute their originally intended request
   or
   4.2 use the store information to notify the owner of the account somebody has failed to perform a sensitive action on their account.

Issue open for discussion.

What do you think about this feature?
Do you see any problems with the description?
Do you think you can write this feature?
Help us improve this project.

BCrypt allows for us to specify a cost, or number of cycles it's gonna run.

BCrypt::Engine.cost = (Rails.env.test? ? 1 : 10)

Decide and implement where that configuration should take place in either of these 2 places.
A. initializer.rb
B. extensions/encrypt_password.rb

Please implement this configuration either way, focusing on which one is easiest for the end-developer to configure in case he wants to change from BCrypt to something else.

Past changes have made Credential be renamed to EmailCredential.
But some places still do use the old name, and that can be misleading to other developers.
Please manage and change this if you can, problematic places can still keep the old name, that's fine.

When the user comes to this page they can no longer see the sidebar,
this is confusing,
please add the sidebar on the sudo_mode/form template following the example on current_users/show and many other template files.

controllers/kicking_concern.rb implements all of our authorization logic in the following methods

kick dont_kick dont_kick_people

they should fall under Goal Authentication.
Please implement documentation anywhere on README.MD explaining how they work.

Do not care so much about where to place the content as it can be moved in the future.

all controllers inside app/controllers implement at least one of the three methods mentioned above.

they do a "pre-authorization" step based on the user model which can be easily...

1. extended by altering user.rb (view issue #12 )
2. extended or replaced by other authorization gems such as cancan, pundit etc...
3. or both 😄

Also note they work at both instance and class level, wrapping a before_action call

Please also open any issues regarding the implementation of KickingConcern if you think it is suitable.

validates_length_of :password messages should be translatable

Such features would be great to have, Github is a great example of how to best implement such features.

validates_length_of :username messages should be translatable

initializer.rb should include this configuration with true as a default value.

config.registration_enabled = true

Decide and implement what perspective a user should have from a website that, for any reason, is not currently taking in new users.

Such features would be great to have, would be great if you could implement gem omniauth as a dependency.
A nice suggestion for implementing this would be inheriting from Credential with STI as we currently already have 2 classes inheriting from it.

module Hello::UserModelRoles should be extracted to templates/user.rb

It should be explicit how to configure Hello's internal authorization system to respond and adept to any complex hierarchy of roles they wish to implement simply by overriding Hello's defaults.

Please find the term "Thread" and help us implement more ruby implementations on .travis.yml or any other tasks that make it threadsafe and compatible with other implementations of Ruby.

Our passwords are not currently being salted
This should be done ASAP because it will create backward compatibility issues.