Skip to content

Add URL to rejection_message if terms_not_accepted

Joshua Gay requested to merge jgay/gitlab:jgay-access-denied-fix into master

This MR is to replace !73555 (closed)

What does this MR do and why?

Describe in detail what your merge request does and why.

When a user attempts to authenticate to a service using Gitlab's OAuth2 service, if the user has not accepted Gitlab's Terms of Use and accepting the Terms of Use is required, then GitLab returns an error message telling the user to go to Gitlab to accept the Terms of Use. However, the error message does not include a URL to the domain where the instance of Gitlab is being hosted.

This MR updates lib/gitlab/auth/user_access_denied_reason.rb so that when a rejection_type is that of terms_not_accepted, that the rejection_message will include a URL to the site hosting the instance of Gitlab that the user should log into in order to accept the Terms of Use. The URL provided to the user is the same URL provided in the use deactivated use case.

The reason this MR was created because the issue described in #212179 (closed) (#212179 (closed)) shows that the OAuth2 error message did not provide to the end-user a URL that they could go to in order to resolve their problem. In this particular case it shows that Mattermost "worked around" this issue by trying to hard-code a URL to the end-user whenever the error message returned by Gitlab's OAuth included the phrase "Terms of Service". The reason it attempted to hard code a URL was because the error message provided by GitLab did not provide it with an error message that it could simply pass along to its end-user. Hopefully this improved error message will make it easier for Mattermost to fix their OAuth2 error message as well as other services attempting to use Gitlab's OAuth2 service for authentication.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports