Feature: Configure switch_user gem to be under development by default about switch_user HOT 13 CLOSED

Hi @lecky, I think that this would be a good idea in most cases, but unlike bullet there is application for SwitchUser in production. The code for this use-case has not yet been made available, but the use-case is a support person who wants to be able to switch to another user from their user in production.

We do currently have guards that will make switch_user available only when you want it. SwitchUser would technically still load, but you could stop the menu from appearing and the controller from accepting requests in production by adding the following:

SwitchUser.setup do |config|
  config.controller_guard = lambda { Rails.env.development? }
  config.view_guard       = lambda { Rails.env.development? }
end

Let me know what you think. I hope my config suggestion represents a good-enough solution to make you happy.

from switch_user.

Hi @lcowell , Not sure if I understand correctly. But I don't think that setting is necessary. If you want switch_user only in production, you can set gem 'switch_user', group: 'production'. Cos Gemfile can already control the gem to load in what environment. Then put the setting in the config/environements/production.rb. And for the menu to show and hide, you can simply modify the condition on the view like what I posted before.

from switch_user.

OK, let's clarify what you're looking for, so I can help you better. I think you're describing how you currently accomplish loading the gem only in development mode. What you're wondering is if it would be possible to make this the default. Do I have that right ?

For example, rather than writing this in your view:

<%= switch_user_select if Rails.env.development? %>

you want to write:

<%= switch_user_select %>

I thought I understood what you meant, but your most recent response is making me thing I'm missing something.

from switch_user.

Yes, you got the main point. But <%= switch_user_select if Rails.env.development? %> is fine for me. What I suggest is the generator could accept rails_env params, so that it can generate the correct syntax and put the configuration in the right environment.

E.g.:
rails generate switch_user:install
This will by default install and configure switch_user into development

rails generate switch_user:install production
This will install and configure switch_user into production

from switch_user.

Hi @lecky, I think I understand what you're saying now. However, this seems like a pretty niche requirement and could be problematic for the average user. My concern is really around having code present that requires switch_user constants, when it isn't loaded. routes will want SwitchUserController, view will want switch_user_select etc etc.. It means that you need conditionals scattered between your views, routes and initializers to prevent the code from being evaluated and throwing an error. For me it would be more trouble than it's worth.

I think the better question for me to ask you is: why do you want to do this ? Is the concern security or perhaps the memory consumption of having unused code loaded ? Perhaps there is some other solution to address your concerns ?

from switch_user.

Yep, it does need a guard to prevent it not being loaded. But I think it's a good to have feature, if you agree that by default switch_user will be in development. And will not load in production. Cheers.

from switch_user.

Can you answer this question ?

why do you want to do this ? Is the concern security or perhaps the memory consumption of having unused code loaded ?

from switch_user.

why do you want to do this ?
It's good to have it in development by default

Is the concern security or perhaps the memory consumption of having unused code loaded ?
unused code loaded. As by default it loads in all environments and configure in initializer. Normally people will have development, staging and production. In my opinion, most cases will be just fast switching users in development programming.

from switch_user.

Hi @lecky, I appreciate the time you've taken to talk to me about this, but I don't think the reasons for adding this are compelling enough. This is especially true with the 0.9.2 release which includes a switch_back feature, which would be useful for help desk staff in an application running in production mode.

I think that what you're describing would be best accomplished with rails templates and rails generators. Using these tools you can arrive at the exact configuration you want with each new project you start.

http://edgeguides.rubyonrails.org/rails_application_templates.html
http://edgeguides.rubyonrails.org/generators.html

If you do build a template or a custom generator, I'd be very interested in seeing what you come up with. I'm going to close this request for the reasons I've stated above.

from switch_user.

Hi @flyerhzm @lcowell . FYI, the initial code is already there:
https://github.com/flyerhzm/switch_user/blob/master/lib/generators/switch_user/install/USAGE

Description:
This generator will create all the necessary files to use and customize switch_user.

Example:
rails generate switch_user:install

This will create:
    config/initializer/switch_user.rb

from switch_user.

Hi @flyerhzm @lcowell, just inspired by http://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/

I think the best practice would be still putting

  gem 'switch_user', group: 'development'

Putting the SwitchUser config under config/environments/development.rb config.after_initilize block same as https://github.com/flyerhzm/bullet

And for view and routes, we can do

  # development-code
    get 'switch_user' => 'switch_user#set_current_user' if Rails.env == 'development'
  # end-development-code

Then we can set a task in Capistrano on deployment called "strip_code" to remove any development code. So this way we can have the functionality we want. And also achieve a cleaner production code base.

from switch_user.

@lecky I'm afraid I agreed with @lcowell , switch_user is different to bullet, it can be used on both development and production, we should not assume users/developers don't need switch_user on production by default. It's developer's responsibility to disable it on production.

from switch_user.

Hi @flyerhzm @lcowell , Setting switch_user to dev by default is just a suggestion. Actually this feature was just open to configuration to load switch_user to development only. As the gem currently default is setting to load for all environment.

As in my case, I only need it to load in dev only. So I provide my suggestion and feedback for the way how I configure it and potentially a way to configure the switch_user gem in a better practise.

Currently, the way how it works just in configuration to enable/disable switch_user in different environment. And in my case, I would suggest better not loading the gem at all in production. What would you think a better way to do it?

from switch_user.