@keavy, can you elaborate a little more on that security need please?
The user needs to be logged in to GitHub in order to install the app. So they’re already authenticated and real as far as GH is concerned. Sending that user to
setup_url takes them off your domain and onto mine, so I promptly launch the oauth flow to send them back to your site, which sends them back to mine (this time with some details of who they are).
This is pretty terrible UX, but setting that aside, I don’t see how it’s required for security (if anything, I thought it’d increase the attack surface by making things way more complicated??. Have I missed something? Transmitting a user/org handle in plain text url encoding wouldn’t be good, but this could be encoded and verified (e.g. the same way as a webhook is secured).
Alternative thoughts about the flow - what about a workflow where GitHub POSTs data (
installation_id etc) to the setup_url endpoint, then expects a
redirect_url as the response, to which it can redirect the user. Thus in the architecture of our GitHub apps we’re separating the user views from the github integration views, which seems to me to be cleaner and allows much more flexibility as far as the content of the