Hey, So the idea behind encrypting the key in the database is the same reason you store the users password as a hash rather than plain text. If an attacker gained access to the database he would have all the api keys and be able to send requests to the site u posing as any user he wanted. In many cases that is irrelevant since you are usually just returning data from the database and he would already have access to that. In my case however, I will also be sending data from external servers and 3rd party providers so gaining access to a users api key would be a security risk.As for sending two keys, it is just an additional level of security and a pretty standard procedure. If you wanted, you could just provide one key and encrypt that in the database using a common encryption secret, but it is better to have a unique secret for every user.

John

Hi Luigi,

No Problem. I actually had to implement it slightly differently because of something unexpectedly. So if you take the same key (I am using a UUID now which has a format of 00000000-0000-0000-0000-000000000000) and encrypt it, I will get a different result each time. This prevents me from looking it up in the database by the encrypted key. What I ended up doing was creating a new field in the keys table called user_uuid. Then when I generate a key, I also generate a second uuid based of of the users name (type 3). This could be a random one as well, but since it doesn't have to be secure I based it off the user name. Then I add the encrypted random uuid to the key field and the non encrypted uuid to the user_uuid field. The the user will pass in the api-key and the user-key. I then look up the key in the database based on the user_uuid and retrieve the encrypted key. Then I decrypt it and check it against the api-key passed in and if they match up then we have a success.

John

Hey Luigi,

I made a few adjustments that I thought you might be interested in. If you want to use them in the future feel free. What it does is add support to return either xml or json depending on the value of the ACCEPT header. It also throws an error if an invalid type or no type is passed in. I also changed it so that if an exception does occur it will not ever display the joomla template wrapper so this makes it so the user will never get html back, which was one of my original questions. What it does it removes he view.html.php under com_jbackend/views/request and adds a view.json.php and view.xml.php as well as some other logic.

I only included the couple files I made and the one I edited in the zip file, not your entire package.

cheers

John