[VERY QUICK & DIRTY FIX] Special case for repositories that only use the token and do not require user on the commit URL

[GwynethLlewelyn]

Ok, so I'm not using a 'public' git repository, but my own private repository, using gogs — it works out of the box, is written in the go language, and has almost all bells and whistles that GitHub, including 2FA, which I'm using — so this issue might not apply to other repositories. In my particular case, when logging in using a token (as opposed to login/password), my repository just requires the access URL to be https://token@my.git.repository.tld/my_user_name/my_grav_project.git — this plugin constantly rewrites it as https://my_user_name:token@my.git.repository.tld/my_user_name/my_grav_project.git which will be rejected with a failed authentication.

I've noticed that git-sync is automatically updating web/user/.git/config (even if I force that file to be read-only!), so I cannot simply 'fix' things by changing the URL there (i. e. deleting my_user_name:): any operation in Grav which will force a git synchronisation will call the code in the git-sync plugin, so it will silently overwrite web/user/.git/config with its own (wrongly) generated URL... and this will happen even if the file itself is chowned read-only (since the .git directory itself obviously has to be read-write...).

Ideally, what ought to be done is to allow the configuration to accept 'empty' user names when using a token, and rewriting the URL to exclude the user name when it is empty. Currently, however, empty user names are not allowed by the plugin admin interface.

My quick & dirty solution was just to add a 'fake' username, NO_USER, and change the URL rewriting rules for web/user/.git/config to ignore both the username and the colon and just use the token (which will be in the password field). My quick fix, however, will then post all git commits as NO_USER, which will look weird on the repository. But at least I can sync with it again!

[w00fz]

Hey @GwynethLlewelyn , sorry for getting back onto this issue only now.

The issue you came across and your suggestion on the resolution were on point. So I went ahead and took your "VERY QUICK & DIRTY FIX" ™️ and expanded on it a little bit more.

There is now a new no_user field in the blueprint that is a toggle for enabling/disabling the user. So not only it will avoid adding the user: in the git request, it will completely ignore the user if it is stored.

I also enhanced the wizard with this functionality, so you can toggle on/off from within the first step whether you want or not to use the user. Looks like this:

Thank you for taking the time to put a patch together and going into details explaining the issue. This is actually better because also GitHub prefers a token alone without the user. I just never realized the user part was being ignored.

Let me know if you see any issues!

[GwynethLlewelyn]

Awesome! My first approved patch — yay! But of course, you really deserve all the credit — for the clean way you have integrated the overall solution. I just 'fixed' things on my own setup but thought that possibly others would also benefit from the 'fix' — after all, I guess that more and more people are avoiding plaintext passwords on their Git config files...