mkdocs-with-confluence icon indicating copy to clipboard operation
mkdocs-with-confluence copied to clipboard

Collaboration and password security - do not embed username and password

Open danizen opened this issue 2 years ago • 4 comments

This seems like a dream come true, but there are problems here with usability and password security. I may not store my password in clear-text in the mkdocs.yml file. Since a piece of code is not my personal possession but something I wish to share with a team, I would also not want to place my username in the mkdocs.yml file.

danizen avatar Jun 28 '22 20:06 danizen

It looks like this could be folded into a better README.md or documentation that mentions JIRA_USERNAME and JIRA_PASSWORD.

danizen avatar Jun 28 '22 20:06 danizen

I also think that since mkdocs configuration already supports using the environment, you drop JIRA_USERNAME and JIRA_PASSWORD and instead educate users how to use them via https://www.mkdocs.org/user-guide/configuration/#environment-variables.

I think there are two ways to work this to be more usable for collaboration:

  • automatically disable the plugin if the config['username'] or config['password'] are missing or NULL, and/or fail with a clean error (rather than an API permission denied error) in the on_page_markdown event.
  • create a console entry point in setup.py (or setup.cfg - see issue #7), which uses the base mkdocs.yml, but inherits from it using Configuration Inheritance, and so injects a prompted username and password. This allows you to test whether the username and password work, and build a new command-line similar to gh-pages.

danizen avatar Jun 28 '22 20:06 danizen

Actually, since mkdocs uses the click library, we can probably just add a command-line sub-command when mkdocs_with_confluence is imported. I will try this and report back.

danizen avatar Jun 28 '22 21:06 danizen

Hi @danizen , great advices, thanks - I would like to collaborate on that, If you are still ok after such amount of time - please drop me an email to [email protected].

P.S. I did it this way without any security as it was used with a 'functional' user, which has not been tied to any particular user and password/credentials were available and public to the whole team as it was for automation purposes. I suppose you are not able to set such a functional user in your case?

Anyway, thanks and I am keeping this topic in my head.

pawelsikora avatar Aug 05 '22 03:08 pawelsikora