https://gitlab.com/users/sign_in 503

[agjs]

Hey guys. I'm unsure if the library is still maintained, but I hope so.

After a simple setup, I keep being redirected to https://gitlab.com/users/sign_in with a 503 error.

1. My client hits http://localhost:3000/auth/gitlab
2. I get a 302 response https://gitlab.com/oauth/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A3008%2Fauth%2Fgitlab%2Fcallback&scope=read_user&client_id=myClientId
3. The previous request calls https://gitlab.com/users/sign_in and I get 503.

If I copy/paste the second step directly into the browser, it actually works. I'm not entirely sure why number 2 tries to call the sign_in URL, but it does.

Any help is highly appreciated.

[Martii]

Our development seems to be working with this dependency at the time of this comment. 503 typically means something along the lines of:

503 Service Unavailable
The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.

302 can be both server and client side... also the main passport dependency. You'll have to narrow it down for this project to perhaps get a little more assistance. :)

[agjs]

Our development seems to be working with this dependency at the time of this comment. 503 typically means something along the lines of:

503 Service Unavailable
The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.

302 can be both server and client side... also the main passport dependency. You'll have to narrow it down for this project to perhaps get a little more assistance. :)

Hey @Martii and thanks a bunch for getting back to me. You are absolutely right, should have provided maybe a bit more information.

So, my API is running on top of Fastify, more specifically, fastify-passport. Alongside Gitlab, I have Github and Bitbucket strategy setup (in the same way) and they both work perfectly.

I'm using the authenticate below with no options as you can see, as read_user is the default scope and the only one I actually need.

   // imported as 
   //    import { Strategy as GitlabStrategy } from "passport-gitlab2";
    passport.use(
        "gitlab",
        // @ts-ignore
        new GitlabStrategy(
            {
                clientID: process.env.PASSPORT_GITLAB_CLIENT_ID,
                clientSecret: process.env.PASSPORT_GITLAB_CLIENT_SECRET,
                callbackURL: process.env.PASSPORT_GITLAB_CLIENT_CALLBACK_URL,
            },
            function (token, refreshToken, profile, done) {
                // asynchronous verification, for effect...
                process.nextTick(function () {
                    return done(null, profile);
                });
            }
        )
    );

    app.get(
        "/gitlab",
        { schema: { tags: ["Auth"] } },
        passport.authenticate("gitlab")
    );

    app.get(
        "/gitlab/callback",
        {
            preValidation: passport.authenticate("gitlab", {
                failureRedirect: "/",
            }),
            schema: { tags: ["Auth"] },
        },
        function (req, reply) {
            reply.redirect("http://localhost:3000");
        }
    );

There honestly isn't much more code then this, apart from serializing and deserializing the user, which again, also works for Gitlab if I copy/paste the actual authorize URL from my developer tools and paste it into the browser.

This is kinda what happens once I hit my /auth/gitlab.

That is more or less all I'm doing, or to say, I'm doing nothing different than what's provided in the documentation.

In the frontend, I'm generally using my own wrapper over Axios, with the interceptors and stuff. I've also tried using native fetch API with follow:redirect option, but this sign_in page always seem to try to render.

[Martii]

Well some of your "bits" are "new greek" to me atm... but did notice this for session management. We have to use lax cookie security for session establishment then elevate to strict. Same goes with using passport with GitHub and every other authentication method we support.

Don't know if this might be an issue with your stack, or not, but could be a starting point with a cookie rejection by the browser/server combo. I'll ponder on this some more after a respite to see if I have my understanding clear on your package though. I've been looking for a "way around" our implementation for quite some time and you have me curious here.

[agjs]

Well some of your "bits" are "new greek" to me atm... but did notice this for session management. We have to use lax cookie security for session establishment then elevate to strict. Same goes with using passport with GitHub and every other authentication method we support.

Don't know if this might be an issue with your stack, or not, but could be a starting point with a cookie rejection by the browser/server combo. I'll ponder on this some more after a respite to see if I have my understanding clear on your package though. I've been looking for a "way around" our implementation for quite some time and you have me curious here.

I'll give you a hand as well and try to debug this. Strange thing though, both Github and Bitbucket are working more or less out of the box, so there must be something very specific to Gitlab that's causing this.

[Martii]

Just a note out loud. So we're using a stateful session vs. what you put up in your request image. Yours seems to show that as a stateless based off the request QSP's.

[agjs]

Just a note out loud. So we're using a stateful session vs. what you put up in your request image. Yours seems to show that as a stateless based off the request QSP's.

Yes, my codebase right now is using Fastify Secure Session, which seems to be stateless. Could this be an issue?

[Martii]

Could this be an issue?

I'm not the expert with passport-gitlab2 however it could be a possibility.

The other item I mentioned earlier is (if) your server stack and browser rejecting the cookie due to lack of permissions.

You may also want to dive a little deeper into the 302 fields your server and browser are getting back... and make sure that GitLab is the one that is truly redirecting you. I've seen Cloudflare (DNS) do that to our users (which really aggravates me on a bad day) and also anything in our express chain/stack that might intercept/trap a request including session management "whoopsies". (tech terms I know ;)

Your dependency mentioned specifically "Difference between fastify-secure-session and @fastify/session" so I assume it means you may want to try to toggle that to a stateful and try that. That might answer your question better. But I am unfamiliar atm with that particular dependency.

[agjs]

Could this be an issue?

I'm not the expert with passport-gitlab2 however it could be a possibility.

The other item I mentioned earlier is (if) your server stack and browser rejecting the cookie due to lack of permissions.

You may also want to dive a little deeper into the 302 fields your server and browser are getting back... and make sure that GitLab is the one that is truly redirecting you. I've seen Cloudflare (DNS) do that to our users (which really aggravates me on a bad day) and also anything in our express chain/stack that might intercept/trap a request including session management "whoopsies". (tech terms I know ;)

Your dependency mentioned specifically "Difference between fastify-secure-session and @fastify/session" so I assume it means you may want to try to toggle that to a stateful and try that. That might answer your question better. But I am unfamiliar atm with that particular dependency.

Gotcha. What I will as you suggested try doing first is, switching to some stateful session and at least writing that off, however it goes.

But I absolutely agree, something is for sure "fishy" in relation to this so it's a good place to start debugging. I'm also running some local proxy, so will check that out as well.

I'll keep you posted once I find something out. And before I forget, thanks a bunch for going back and fourth. In case this turns out to be something related to this repo itself, I'll make sure to do a PR.

[Martii]

Here's some refs that seem to pertain to a bit of the discussion:

• state for passport causes fastify-passport to fail fastify/fastify-passport#376
• Add a "proxy" flag to support setting the values directly on the session object. fastify/fastify-secure-session#113 (Note this is currently open)

If I'm reading this, and fastify/fastify-passport#376 (comment) specifically, correctly you are probably running into a stateless issue with stateful sub-deps like this repo. Can't tell you why you said it does work with your other auth methods just yet. I need slumber though and I'll dig some more.

[agjs]

Hey @Martii. It seems that the above PR's have been merged, but I still seem to be getting the same error. Is there something you could take a look now as well, considering the above is already merged.

Cheers