Gitlab Authentication not working #1930

New Issue

OVERLORD · 2026-02-05T02:14:25+03:00

OVERLORD commented

2026-02-05 02:14:25 +03:00

Originally created by @serge-kilimoff on GitHub (Nov 7, 2020).

Gitlab authentication is not working.
GITLAB_APP_ID, GITLAB_APP_SECRET and GITLAB_APP_URI have been correctly entered.
When redirecting to my Gitlab (self-hosted), the url contains an empty scope = parameter. However, Gitlab does not seem (or no longer) to accept empty scopes.

A temporary fix that I made on my side is to add in the file app / Auth / Access / SocialAuthService.php, in the function getSocialDriver an additional condition:

    /**
     * Provide redirect options per service for the Laravel Socialite driver
     */
    public function getSocialDriver(string $driverName): Provider
    {
        $driver = $this->socialite->driver($driverName);

        if ($driverName === 'google' && config('services.google.select_account')) {
            $driver->with(['prompt' => 'select_account']);
        }
       
        if ($driverName === 'azure') {
            $driver->with(['resource' => 'https://graph.windows.net']);
        }
        // BEGIN Dirty-fix
        if ($driverName === 'gitlab') {
            $driver = $driver->setScopes(['read_user']);
        }
        // END dirty-fix
        return $driver;
    }

I put read_user, but it's definitely too high a permission.

Gitlab version: 13.5.3

Thank you very much !

Originally created by @serge-kilimoff on GitHub (Nov 7, 2020). Gitlab authentication is not working. GITLAB_APP_ID, GITLAB_APP_SECRET and GITLAB_APP_URI have been correctly entered. When redirecting to my Gitlab (self-hosted), the url contains an empty `scope =` parameter. However, Gitlab does not seem (or no longer) to accept empty scopes. A temporary fix that I made on my side is to add in the file `app / Auth / Access / SocialAuthService.php`, in the function `getSocialDriver` an additional condition: ```php /** * Provide redirect options per service for the Laravel Socialite driver */ public function getSocialDriver(string $driverName): Provider { $driver = $this->socialite->driver($driverName); if ($driverName === 'google' && config('services.google.select_account')) { $driver->with(['prompt' => 'select_account']); } if ($driverName === 'azure') { $driver->with(['resource' => 'https://graph.windows.net']); } // BEGIN Dirty-fix if ($driverName === 'gitlab') { $driver = $driver->setScopes(['read_user']); } // END dirty-fix return $driver; } ``` I put `read_user`, but it's definitely too high a permission. Gitlab version: 13.5.3 Thank you very much !

OVERLORD added the 📖 Docs Update 🚪 Authentication labels 2026-02-05 02:14:25 +03:00

OVERLORD closed this issue

2026-02-05 02:14:29 +03:00

OVERLORD commented

2026-02-05 02:14:39 +03:00

@ssddanbrown commented on GitHub (Nov 7, 2020):

Thanks for reporting @serge-kilimoff.

I've just spent some time investigating this.

Looks like previously you could create an "Application" within GitLab without selecting scopes, which would then work when no scopes are provided. Looks like you can no longer do this since you're forced to make a selection. I'm unsure if this would previously give that application all permissions or a minimal set. Potentially it would have given all since I see that, when you select all scopes at least, it does enable the current functionality to work. Of course it is better to use the minimal scope.

This is something I'll look to create a PR for in the upstream package we're using. Before I do, You mentioned:

I put read_user, but it's definitely too high a permission.

Is there a better permission to use? That looks to be the most applicable within my view and is what I'm seeing in use by some other packages.

Resources for my future reference
60e58096a7
https://github.com/SocialiteProviders/Providers/tree/master/src/GitLab

@ssddanbrown commented on GitHub (Nov 7, 2020): Thanks for reporting @serge-kilimoff. I've just spent some time investigating this. Looks like previously you could create an "Application" within GitLab without selecting scopes, which would then work when no scopes are provided. Looks like you can no longer do this since you're forced to make a selection. I'm unsure if this would previously give that application all permissions or a minimal set. Potentially it would have given all since I see that, when you select all scopes at least, it does enable the current functionality to work. Of course it is better to use the minimal scope. This is something I'll look to create a PR for in the upstream package we're using. Before I do, You mentioned: > I put `read_user`, but it's definitely too high a permission. Is there a better permission to use? That looks to be the most applicable within my view and is what I'm seeing in use by some other packages. **Resources for my future reference** https://github.com/Laravel/socialite/commit/60e58096a784bacbb5685450d3fc29251c3914fd https://github.com/SocialiteProviders/Providers/tree/master/src/GitLab

OVERLORD commented

2026-02-05 02:14:45 +03:00

@serge-kilimoff commented on GitHub (Nov 7, 2020):

I confirm that it worked before without scope, and that it was possible to put an application without choosing anything. I still have apps configured this way, but that's old story now.
Regarding the second point, I am not English speaking (French speaking) and I sometimes use translation software (I have no problem reading, but writing is a little more complicated). I didn't mean "definitely too high permission" but "are there any lower permissions?", like a question.
read_user has read-only access to all user data, sounds like tip-top to me for this usage.

@serge-kilimoff commented on GitHub (Nov 7, 2020): I confirm that it worked before without `scope`, and that it was possible to put an application without choosing anything. I still have apps configured this way, but that's old story now. Regarding the second point, I am not English speaking (French speaking) and I sometimes use translation software (I have no problem reading, but writing is a little more complicated). I didn't mean "definitely too high permission" but "are there any lower permissions?", like a question. `read_user` has read-only access to all user data, sounds like tip-top to me for this usage.

OVERLORD commented

2026-02-05 02:14:50 +03:00

@ssddanbrown commented on GitHub (Nov 7, 2020):

@serge-kilimoff Awesome, Thanks for confirming.

@ssddanbrown commented on GitHub (Nov 7, 2020): @serge-kilimoff Awesome, Thanks for confirming.

OVERLORD commented

2026-02-05 02:14:55 +03:00

@ssddanbrown commented on GitHub (Nov 7, 2020):

PR opened in https://github.com/SocialiteProviders/Providers/pull/582

Will look to include in next feature release (v0.31) once merged. Wouldn't really look to include in a sooner patch release since it could be a breaking change in some instances.

Note to self - For Update Docs when Released

"Applications" within GitLab, created for BookStack authentication use, will need to have the read_user scope assigned. Not having this scope may lead to errors when users attempt to authenticate via GitLab.

Also need to document the PHP version change required as per changes in 2b603b0488.

@ssddanbrown commented on GitHub (Nov 7, 2020): PR opened in https://github.com/SocialiteProviders/Providers/pull/582 Will look to include in next feature release (v0.31) once merged. Wouldn't really look to include in a sooner patch release since it could be a breaking change in some instances. ### Note to self - For Update Docs when Released "Applications" within GitLab, created for BookStack authentication use, will need to have the `read_user` scope assigned. Not having this scope may lead to errors when users attempt to authenticate via GitLab. Also need to document the PHP version change required as per changes in 2b603b048835a00552fcebac834e9f27ea49beaa.

OVERLORD commented

2026-02-05 02:14:59 +03:00

@cfreeman29 commented on GitHub (Nov 16, 2020):

Would like to add I had this same exact problem with a docker image of Bookstack and an on-prem instance of gitlab. After using the hot fix with it worked as intended.

@cfreeman29 commented on GitHub (Nov 16, 2020): Would like to add I had this same exact problem with a docker image of Bookstack and an on-prem instance of gitlab. After using the hot fix with it worked as intended.

OVERLORD commented

2026-02-05 02:15:03 +03:00

@ssddanbrown commented on GitHub (Dec 18, 2020):

PR was merged and included in the project as part of 2b603b0488 so I'll therefore close this.

Will be part of BookStack v0.31.

@ssddanbrown commented on GitHub (Dec 18, 2020): PR was merged and included in the project as part of 2b603b048835a00552fcebac834e9f27ea49beaa so I'll therefore close this. Will be part of BookStack v0.31.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1930