Github App Installation Setup URL does not preserve state query parameter

[sid374]

Select Topic Area

Bug

Body

We're creating a new Github App with the following expected installation flow:

1. We link to the github app installation like so: https://github.com/apps/sid-quickstart/installations/new?state=foo (Notice the state=foo query parameter)
2. The github app is configured with a setup url to our server
3. Once we get the redirect from github after the app install we look for the query parameter state in order to link the user identity to our system and protect against CSRF attacks

This is pretty standard oAuth stuff. However, we noticed that when Github redirects to our setup url, it does not preserver the state query parameter, and we're unable to complete the loop. I tried very hard but couldn't find any documentation about this either.

Interestingly if we link the user to the following installation url: https://github.com/apps/sid-quickstart/installations/select_target?state=foo - the state query param is correctly preserved when our setup url callback is called.

Can someone please help or clarify the expected behavior here?

[sid374]

@jamesmartin I've noticed that you've answered similar questions in the past - would you be able to help please?

[tihal]

+1 on this - seeing this behavior pop up just today. Our app installation and oauth flow was working yesterday, but today things are breaking because state is not being returned to our callback. Did something change on Github's end?

[handotdev]

+1 as well. Our GitHub apps are not working in production, and is affecting a lot of customers. Would really appreciate a fix asap

[coffeewithone]

+1 GitHub apps are not working and this is negatively affecting our customers! :(

[ojaswa1942]

+1
This affects our production as well.

[tamsalem]

+1 affects our prod, any ETA?

[livnoni]

Hi Github team,
iI effect our production environment - Is there a time estimate for fixing the bug?

[hlevian]

+1
We are getting this error in our Production env and major customers, we'll appreciate a response here.

[kaje94]

+1
This is affecting us as well

[naposysdig]

+1

[richardguerre]

We have migrated to the new /select_target path and we would prefer not getting the rug pulled under us again (please don't change it back to /new).

[livnoni]

we also made the same fix.
please don't change to /new again.

[petebacondarwin]

Looks like Github have implemented a 302 redirect from /new to /select_target but failed to pass through the search params.

[FaizanNoor]

+1 on Production.

[alerosa]

+1

[kozliuk]

+1

[lyzohub]

+1

[hpsin]

Hey folks, thanks for reporting this. We have a fix in testing right now, about to be deployed. The select_account route is a new endpoint that's internal to the OAuth flow - please don't link to it. /new remains the correct endpoint.

[mikeurbanski1]

+1

[HubbardJacob]

Thanks so much for the update!!!

[hpsin]

It's merging now, and I'll ping here when it's fully deployed.

[hpsin]

Alright, this is fixed, apologies for the impact here.

[RoxKilly]

This is possibly related to https://github.com/orgs/community/discussions/64239

[phantomcloud-io]

Any updates? It seems if the state is took long it wont pass

[M3tbe]

Seems the problem is back

[M3tbe]

https://github.com/orgs/community/discussions/125561

[vedant-contentstack]

Do we have any updates on the following???