Use an external configuration file.

[Zegnat]

Passwords are best stored away from third-parties, and although PHP code should not be readable it is not unheard of to have a server misconfiguration leak PHP code in plaintext.

By storing the configurations (including the password) in an external file, this file can be put outside of the publicly accessible server directory.

[stephanepechard]

That's why other implementations use a ~/.photobackup INI file to store this. Plus, with the help of Nick Thomas (the Go server implementation maintainer), I do not store the SHA-512 hashed password anymore (though it can be still be here for backward compatibility during API v2) in this file, but a Bcrypt version of it. You can see the implementation in the Python or Go implementations. Do you think it would be possible to do the same in PHP?

I should better document such features, there's a server.md file in the API repository, but it is not accurate anymore...

[Zegnat]

An API should only specify how software talks with a server, not how a server works, so it doesn’t really matter how and where this is specified.

The problem with PHP is not so much what it can and can’t read, the problem is what hosting providers will allow. I want this implementation to be easy to use for anyone, no matter what hosting provider they want to run it on. Very few hosting providers will allow me to read and write from arbitrary paths like the user directory, so that is definitely out.

Another problem, which is why this issue has the documentation label attached, is that we need to explain to people that an external configuration file only works when put outside of the server’s public directory. Some hosting might not allow you to upload outside of there, in which case it is safer to stick with the current format. A .photobackup or config.ini file in the public directory will just be readable by everyone and that mistake is easily made.

[stephanepechard]

Ok, so this is kinda specific to PHP, right? In this case, I let to you how to handle it in the proper manner.

Considering what you said about the API and in order to provide documentation to developers who want to help us, do you think we should:

• create a new documentation repo?
• rename the api repo into documentation and include the api.raml in it?
• put such documentation into existing repos, each server or client being totally independant, with probably lots of redundancies?
• or maybe create a servers repo for server documentation and a clients repo for client documentation ?