Github Enterprise Support

[cgatian]

Support on prem Github Enterprise.

Investigating if this is a simple change to the host location.

[cgatian]

Looks like GHE uses a differrent mechanism to prevent CSRF. This probably isnt possible without reverse engineering the PR form and changing the mechanics of this library entirely.

[drogers0]

Thanks for digging into this, and for reporting back what you found rather than leaving it open-ended.

To set expectations up front: I'm open to GHE support landing in gh-image, but I can't drive it myself. I have no access to a GHE appliance, so I can't reverse engineer the upload flow or test any change against a real instance. If someone with appliance access wants to do the investigation, I'll gladly review and merge a PR.

Some findings that might help scope it.

My Understanding of the differences

gh-image reproduces what your browser does on drag-and-drop, as plain HTTP requests. Here is each step and what is known or unknown about its GHE equivalent:

Step	github.com	GHE appliance
1. Session	Reads user_session from the local browser cookie store, filtered to domain github.com	Same cookie store, different domain. Mechanical change — swap the domain filter and jar URL
2. Upload token	GET /<owner>/<repo>, then regex "uploadToken":"…" out of the page's embedded JS payload	Unknown whether that string exists in GHE's HTML at all. Nothing downstream can work without it
3. Policy request	POST /upload/policies/assets, sending the token as authenticity_token, plus a __Host-user_session_same_site cookie that gh-image synthesizes by copying the session value	Where your CSRF finding lands. Note the same-site cookie is fabricated, not read from the browser — if GHE validates differently, no amount of host config fixes it
4. File upload	POST the bytes to a presigned S3 form (X-Amz-* fields) returned by step 3	Appliances normally have no S3 — attachments are stored and served locally by Alambic. The policy response shape likely differs, and gh-image currently hard-fails when the form fields are absent
5. Finalize	PUT the returned asset_upload_url, receive https://github.com/user-attachments/assets/<uuid>	Appliance attachment URLs look like https://<host>/storage/user/<id>/files/<uuid> — different shape entirely

Steps 1 and 5 look mechanical, but 2, 3 and 4 can't be settled without hands-on testing against a real appliance, so this needs someone with GHE access to take it forward.

[cgatian]

That aligns with what I saw. I got it pretty far then backed out the code changes because it wasn't a simple host replacement.