Prevent demo users from changing the password and the email about homebugh HOT 8 CLOSED

I will create the migration myself

I think @phunq-0851 wanted to work on the migration. For your changes you can define a temporary method in the User model

def demo_user?
  email == "[email protected]"
end

from homebugh.

Hi @ck3g , I think I could work on this ... is it ok?

from homebugh.

Hey @m8051 absolutely

from homebugh.

@ck3g I have been thinking about it and I believe we could disable the inputs in the /users/edit form along with the submit button, instead of replacing them with texts.

My idea is to implement a very basic boolean method in the ApplicationController that checks if @user.email is '[email protected]'.

  def demo_user?
    true if @user.email == '[email protected]'
  end

Then disable the inputs and submit button in the edit.html.haml

%h2= t(:profile)
= simple_form_for(resource, as: resource_name, url: registration_path(resource_name), html: { method: :put, class: "form-horizontal" }, defaults: { disabled: (demo_user?) }) do |f|
  = f.error_notification
  .form-inputs
    = f.input :email, required: true, autofocus: true
    = f.input :password, autocomplete: "off", hint: t("devise.registrations.leave_it_blank_if_dont_want_to_change"), required: false
    = f.input :password_confirmation, required: false
    = f.input :current_password, hint: t("devise.registrations.need_current_password_to_confirm"), required: true
  .form-actions
    = f.button :submit, t(:update), class: "btn btn-primary", disabled: (demo_user?)

Would you be happy with these changes? I can see an issue hardcoding the address. Maybe we can use the first method, which would return the first record created through seeds instead.

Or better to stick to the original plan?

I would like to know your thoughts on how you would like implement it ...

Thank you.

from homebugh.

@m8051

When we add a new column with the boolean value here #34 we will get the demo_user? method for free.
But in the meantime, we can introduce the method as you're suggesting, to make the form work. You can check against the following email for now: [email protected].

We can disable fields as well, that's absolutely fine. The problem with the disabled fields is that anybody can inspect the page and change their values to not disabled and submit the form. That's why (in the separate issue) we need to prevent updates for demo users as well.

To summarize. The solution you're suggestion is fine. Feel free to proceed.

from homebugh.

Oh I did not notice issue #34 will give us the demo_user? for free, brilliant

You are right anyone could manipulate the form and submit it by inspecting the source code.

Was your original idea based on checking the demo_user value and render two forms ?

Thanks @ck3g

from homebugh.

Was your original idea based on checking the demo_user value and render two forms ?

Not sure I understand the question.

The main idea here is to prevent changing credentials for a demo user. On the /users/edit page we need to check for current_user.demo_user? and alter the view when it's true. We can replace it with text, or disable the form to make it read-only.

So the page will behave normally for all of the users, allowing them to change their password or email. But it will be a read-only form (or text view) for the demo users.

Let me know if that makes sense.

from homebugh.

Yes makes a lot of sense, I will create the migration myself based on #34 and implement what we discussed above ^^

from homebugh.