Store password for ustore connect and XMPIE API (WS+REST)
65 views
Skip to first unread message
Yannick
Sep 15, 2022, 9:52:57 AM9/15/22
to XMPie Interest Group
Hi,
Simple question:
With uStore Connect, how do you store the password?
1. The user is logged on an external website.
2. For products groups, you can use the REST API and then you will use the WS API to get the iframe URL.
For the both API, you must known a username (email) and the password. The uStore credentials.
But if the user doesn't exists in uStore, you must create this one, and again, to call the API you must provide the password.
Where do you store the password? Because you cannot save it into your database in clear.
2. For products groups, you can use the REST API and then you will use the WS API to get the iframe URL.
For the both API, you must known a username (email) and the password. The uStore credentials.
But if the user doesn't exists in uStore, you must create this one, and again, to call the API you must provide the password.
Where do you store the password? Because you cannot save it into your database in clear.
west-digital.fr
Sep 15, 2022, 11:18:47 AM9/15/22
to XMPie Interest Group
Hello,
Usually, our customers decide a given, rather complex password, used for all uStore Connect users - anyhow, the users will not login to the application via the uStore Login page, but via the 3rd party application. So, they do not need (and must not know) their actual uStore password.
Yannick
Sep 15, 2022, 4:25:15 PM9/15/22
to XMPie Interest Group
Hi,
thanks for your answer. The third party application is the site where the iframe is ? They don't need to know the password but it's save into the database in clear, right ?
west-digital.fr
Sep 16, 2022, 2:59:12 AM9/16/22
to XMPie Interest Group
Yes: sorry for naming the "host application" a 3rd party - let's say it's a CMS like Prestashop of whatever.
Usually, as the uStore Connect password is the same for all users (as I wrote above), our customers do not store it in the Host application's database (per user), as it would make useless duplicates.
Instead, they store it in a server-side configuration file of the Host application - or, why not, in a specific "configuration" record in the database, if they like it.
"Clear or not clear?" Anyhow, the call to the uStore Connect API is made via HTTPS, so it's not so different than a user typing a password "in clear" in a Login page field. Now, if the Host application developer prefers hashing the password, store the hashed value in his configuration file / configuration record, then unhash it, when he/she needs to call the uStore Connect API, for sure it's an extra security.
Reply all
Reply to author
Forward
0 new messages