Skip to content

Option to explicitly enable or disable optional client certificates #1138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 14, 2022

Conversation

oddeirik
Copy link
Contributor

Ref #1137 this setting allows you to disable optional client certificate authentification as well.

I've tested this on my server and there's no longer any prompt to pick a user certificate when connecting to the web interface.

You might want to change the wording or the name of the setting to something you see more fit, I just tried matching the requireClientCertificates setting.

@john-brice
Copy link

Did this PR make it in to 1.9.0?

@flaix
Copy link
Member

flaix commented Apr 1, 2020

No, this is still open and on the list.

@flaix flaix linked an issue Aug 7, 2022 that may be closed by this pull request
@flaix
Copy link
Member

flaix commented Aug 7, 2022

I would prefer to not add a second option and expose the ambiguity of Java SSL in this case. I could imagine that the existing option is converted from a boolean to hold either an additional off value, or three completely different values like required, optional, none, or like Tomcat with true, want, false.
I guess the question is if this needs to be done in a backwards compatible way or if the meaning for false could be changed because everyone who has it set to false wants it off anyways.

@flaix flaix merged commit 1df20a0 into gitblit-org:master Aug 14, 2022
@flaix flaix added this to the 1.10.0 milestone Aug 14, 2022
@KOTRET
Copy link

KOTRET commented Aug 15, 2022

Converting to true / want / false would be a good solution, for me it seems to be compatible: only those who want to have this optional need to change that setting, which - I would think - is not the vast majority.

@flaix
Copy link
Member

flaix commented Aug 15, 2022

Well, I had opted for the first one now, in the spirit of keeping backward compatibility. The three new values are required, optional and none. I did this so that an update would not change existing behaviour, which would be a surprise I myself don't really like. So the existing true and false values keep their meaning and are mapped like so:
true = required
false= optional

While it could be true that in reality hardly anyone would be affected, I unfortunately have no idea how many people still use Gitblit, i.e. how large the existing user base is that could be negatively affected. I don't think download numbers really mirror installed base.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Disable client certificates entirely
4 participants