Enable extra user preferences for remotely authorized users

[maartenschermer]

These changes enable editing of extra user preferences (if enabled in Galaxy conf) for users that are authorized remotely (use_remote_user: true). In the current version, when authorized remotely, the extra user preferences interface in the webapp is automatically disabled together with the editing of email address and username. This PR enables the editing of the extra user preferences, while still disabling editing email and username.

Fixes #18823

Files changed:

• front-end: UserPreferencesModel.js (to make the 'Manage information' link appear when authorized remotely)
• middleware: remoteuser.py (added the user/information URL to allowed paths)
• API: users.py (to disable email/username when authorized remotely)

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. Set use_remote_user: true in Galaxy conf and implement remote auth (for instance by injecting REMOTE_USER in your request headers)
  2. Enable extra user preferences via config/user_preferences_extra_conf.yml and add some preference input for testing.
  3. Restart Galaxy, and test via User > Preferences > Manage information

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[dometto]

@dannon can you perhaps let us know a timeline for reviewing this? Is there anything we can do at this stage? The test failures seem unrelated, to do with the iRODS data source, and seem to happen on at least some other PRs as well.

[dannon]

@dometto Thanks for the ping, apologies for the delay -- I will set up external auth and test this this morning.

[dannon]

Tested w/ a local remote user setup -- this is working well for me and I can now edit preferences as a remote user. Thanks @maartenschermer, @dometto !

[github-actions]

This PR was merged without a "kind/" label, please correct.