Allow users to commit using both corporate and external email addresses

[andypols]

Is your feature request related to a problem? Please describe.
This is a variant of #1210. We have many open-source contributors who wish to commit using their external GitHub email addresses. We’d like to extend the git-proxy service to support this.

At present, each user has a single email address associated with their account — in our case, the corporate email provided via SSO.

When a user pushes a branch, git-proxy uses this email to verify whether the user is authorised to contribute to the target repository. Commits from any other email address are rejected.

Describe the solution you'd like
Allow users to add additional external email addresses.

Extend checkUserPushPermission to validate authorisation against any verified email address linked to the permitted contributor.

[kriswest]

While I support the presence of this feature in Git Proxy, we have a policy that requires the use of a corporate email address (as this publicly links contribution to the organisation and helps us differentiate someone personal contributions to projects on their own time). I believe others have the same policy (@grovesy said the same of Citi - that might mean #1210 is no longer relevant to @06kellyjac ...). We'd like a config option that disables this feature and any related UI controls.

While I'm at it, we are accumulating a number of config features that a new adopters needs to understand and make decisions about when they set-up git proxy. At the minimum all config features should include schema additions describing their settings - But I think we could go further and put some more thought into the Configuration overview and call out features that you should consider on first setup - which should definitely go into where config is loaded from @jescalada. I've also just noted the Pre-receive hooks section which is entirely anachronistic I think (having been replaced by processors and plugins?).

All that is to say, we need another issue for additional work on documentation for settings like these - we have not put work into docs in a while other than documenting parts of the schema. Future issues like these should all have to contribute into the docs before PRs are complete/accepted IMHO.

[kriswest]

Raised #1272 for a review of the docs and planning out what we need to do... Would love PR authors to consider config schema and intro content in the mean time.

[kriswest]

... which should definitely go into where config is loaded from @jescalada

I misspoke, that is actually covered at https://git-proxy.finos.org/docs/configuration/overview#configuration-sources. although it might be worth an earlier narrative on it...

[andypols]

it makes sense that git-proxy needs to support multiple company email policies. As a new adopter, I agree that the documentation could use some attention, and I’d be happy to help improve it.

@kriswest, I’m not entirely sure what you meant by your reference to the configuration sources. I would have thought an organisation’s email policy would be a core decision for new adopters.

[kriswest]

@kriswest, I’m not entirely sure what you meant by your reference to the configuration sources. I would have thought an organisation’s email policy would be a core decision for new adopters.

Just going down a rabbit hole on the flaws in the introductory docs - not directly related to this story.