-
MySQL :: MySQL 5.7 Reference Manual :: 5.6.6 mysql_config_editor — MySQL Configuration Utility
May 3, 2017 at 2:18:46 PM GMT+2 - permalink -Exactement ce que je cherchais
You can use the mysql_config_editor utility to store authentication credentials in an encrypted login path file named .mylogin.cnf.
To create a new set of credentials run:
mysql_config_editor set --host=db.host.org --user=dbuser --password
and enter your password when prompted.
This will store your authentication credentials in the default client login path.
You can store multiple authentication credentials by specifying a different --login-path option:
mysql_config_editor set --login-path=db2 --host=db2.host.org --user=dbuser --password
By default, the mysql client reads the [client] and [mysql] groups from other option files, so it reads them from the login path file as well. With a --login-path option, client programs additionally read the named login path from the login path file. The option groups read from other option files remain the same. Consider this command:
mysql --login-path=db2
The mysql client reads [client] and [mysql] from other option files, and [client], [mysql], and [mypath] from the login path file.
To print out all the information stored in the configuration file run:
mysql_config_editor print --all=true
More information about the utility can be found at "mysql_config_editor — MySQL Configuration Utility".
-
https://dev.mysql.com/doc/refman/5.7/en/mysql-config-editor.html
-
![thumbnail]()
Principles for Standardized REST Authentication - O'Reilly Broadcast
January 18, 2017 at 10:38:03 AM GMT+1 - permalink -Stateless auth for rest api
Query Authentication
All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private credential as the signing token. Signing should occur before URL encoding the query string.
In other words, you don't pass the shared secret component of the API key as part of the query, but instead use it to sign the query. Your queries end up looking like this:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
The string being signed is "/object?apikey=Qwerty2010×tamp=1261496500" and the signature is the HMAC-SHA256 hash of that string using the private component of the API key.
The main objection to this approach is that the private API key devolves into a kind of password for static calls. For example, if the query were instead:
GET /object?apiKey=Qwerty2010
The signature would be the same every time you made that specific query. However, you are using SSL, right? Furthermore, adding in a timestamp makes each query differ. For extra security, you can make the timestamp a more formal date-time value with time zone information and disallow queries outside of the query range.
The real controversy is whether signing should occur before or after URL encoding values. There is no "right" answer. I lean towards signing before encoding because most programming tools make it easier on the server side to get the unencoded values versus the encoded values. I'm sure good arguments can be made the other way. What I really care about is this: let's pick one and stick with it.
-
http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html
-
totp [sebsauvage]
July 18, 2014 at 9:36:50 AM GMT+2 - permalink -HMAC-based One-time Password : pour se faire l'équivalent d'un token rsa (genre securid) soi-même en utilisant son smartphone, c'est top et facile à mettre en place :)
-
http://sebsauvage.net/wiki/doku.php?id=totp&#codiad
