@yisrael-wix Any progress to share?
@reveel @yisrael-wix Dear All,
I thought I would just like to mention that I have been working on a work around at present in relation to this, I have managed to create with the help of @brainstorrrm a number of MFA processes for customers on my wix website, I have email verification, password verification, One Time Access and also utilised the OTP method above as well as SMS verification all working from the backend. As @brainstorrrm m has stated all of this is great for clients however if the main account is someway compromised and data accessed by malitious intent, I have taken an added step and encrypted all uploaded customer data that is text, url and all security codes for the above methods of MFA/2FA. However again this is only as secure as my Wix website dashboard, and it would be good to either have 2FA on the account or an email confirmation that you have logged in to your account and from what device etc a bit like facebook. This should not be hard to achieve.
Best Regards
Si
@simonadams @brainstorrrm
I do agree, and that is why I wanted to clarify his remark on it being worked on - to ensure it is for our site-access as Admin/Contributors, because I don’t think we should have much API access to that side. Altho - APIs for our site-members would be nice too.
I’d like to move this off of my post, and start a new one. I’d join you all there. I’ll let one of you ( @brainstorrrm -OR- @simonadams ) decide on who will own the post. Do let me know the link that way I can follow it. Thank you
Update : I created another post to carry the 2FA motion forward. Here is that link:
https://www.wix.com/corvid/forum/community-feature-request/security-policy-for-wix-site-site-admins-owner-s-log-in-access-not-our-site-s-customers-members
@yisrael-wix
Hey bud I hope you had a good weekend.
How are we looking on this? I am happy to run through some ideas to get this working; that is in an easy and safe manner for Wix.
I know you are buys too, but I really need to get this working. Thank you in advance.
Hey bud I hope you had a good weekend.
How are we looking on this? I am happy to run through some ideas to get this working; that is in an easy and safe manner for Wix.
I know you are buys too, but I really need to get this working. Thank you in advance.
(adding as a post since I noticed replies get buried after many).
I couldn’t find anyone here who’s implemented the API access as you want. The closest I’ve seen is what @brainstorrrm has - maybe you could adapt it for your own use.
I believe that a method for secure access to exposed APIs will be offered at some point, but I can’t really say when.
@yisrael-wix
Can we get the Corvid team to allow/expose the ‘wix-users’ library for the “http-functions.js” file only (instead of everywhere)? - it is understandable not to expose that for other reasons, but technically the ‘wix-users-backend’ has the more dangerous actions like “deleteUser()”, Etc. Therefore, what ‘wix-users’ offers is not as harmful. Alternately, at the very least, can we get someone to expose the one function “login( )” from ‘wix-users’ only for/from “http-functions.js”?? - Pleeeeeaaasee!!
From what I see in other posts including @brainstorrrm those solutions do require the users to take action, and not through an end-point. To be clear we don’t have to do an official OAuth - since that is a bit more (technical nuance) than what we are doing here. All we need is to allow the login’s 2nd leg to actually finish up.
I have some good news! In fear that the “login()” may not be exposed or even promptly. I started digging through and came up with a solution that is working. It is not ideal, but I can add my own security layer and feel okay with it. In case this is something that you don’t want published I will not provide the source code or how I did it. If you’d like for me to share directly with Wix/Corvid team so that someone can verify my solution first (before providing on forum), please shoot me an email from your back end. If you do approve what I’ve done I can publish it thereafter.
If you are able to place my original request on a feature request and/or able to make it happen please do let me (& us the forum) know. Thank you.
@simon.adams @brainstorrrm
I had not heard from either of ya, and felt your mission was worthy. So I posted a Feature Comment. Here is that Link:
https://www.wix.com/corvid/forum/community-feature-request/security-policy-for-wix-site-site-admins-owner-s-log-in-access-not-our-site-s-customers-members
I plan on calling in today to make feature request via Wix too.
Did you actually find a way to do this? I would like to expose REST APIs to my mobile app and I really need this functionality.
@yisrael-wix any official answer for the above?
Thanks much!
@deleteduser Thanks much! This means we’ll need to bring up a webkit view for the login and that would solve the initial login but then I wonder for the rest of the native mobile pages how we could secure the HTTP/Backend/Database chain so we don’t just rely on suppressAuth mechanism for database access as this could be highly unsecure. Any ideas?
I was able to create a secure flow to do this. Although, it is not something that is able to be done via the features and APIs available from Wix/Corvid alone. I ended up writing a set of decent services for Wix (frontend and backend) and each mobile app platform. Normally, I would have abandoned using the Wix platform but for some (odd) reason I decided to write many days of code to achieve this. Timewise was not proper decision.
Unfortunately, until Wix exposes the library (or the 1 needed function), this will not be possible. My thinking is that Wix/Corvid won’t do that, so it may end up being a feature request for a new type of API. Based on your needs you could try an alternate by using javascript injections.
Alternately, try javascript injection.
NOTE: I was able to figure out how to do this and did successfully make a test login work – not thoroughly tested (sorry I did not save the code).
In order to get javascript injection to work, there is a small nuance trick to know. That, which is you’ll need to make a custom signup form, which is a Lightbox. Luckily, with Wix you can add code to the Lightbox, which is the gate where any pending log-in sits (regardless of the attempted member-only page). That is where you can add code to allow and handle your javascript injections to log-in your users. Also, by customizing this form, you can eliminate the extra stuff, so that you do not complicate your scripts. From there like @deleteduser mentioned, you can use the sample code(s) I posted along with Wix API reference’s sample code(s) to complete. Make sure to only use one custom signup form for all users, otherwise it will complicate things - not a blocker just more complicated.
Some Code Hints :
In my testing I used the ’ $w.onReady( ) ’ and its related Functions/Properties on the Lightbox. Also, the ’ wix-window ’ library can be useful too, since it can post messages and track events,
Is it secure to send the password over a http-request? I understand that with https the password is base64 encrypted, but would the password be logged in the browser history? Are there any other security considerations here?
p.s. thanks for hashing all of this out publicly, you will no doubt have helped a lot of people, including myself
@reveel I’ve been trying to make this work, but so far have been unsuccessful. Would you be willing to post any more information about the solution that you found? I’d be very interested to learn how you structured the flow as a remote login via http is exactly what I’m working on right now.
Thanks
As general rule, passwords sent over HTTP (without SSL) are unsafe. Normally browsers (as a standard) recognize security protocols for encryption with the HTTPS protocol. Which then (w/HTTPS) means your information being exchanged is encrypted, and can even prevent (not always) against MITM (Man In The Middle) attacks.
Terminology Side Note:
Also, some info on using the term HTTP-Request alongside HTTP/HTTPS. Those terms (its usage) can get confusing, since HTTP-Request is (usually for coding) intended to refer to the type of transaction (in coding for handling any protocol for HTTP) and not the security/layer protocol. Whereas, HTTP vs HTTPS is the protocol, and thereby HTTPS is for what you are mentioning is handled through Transport Layer Security (TLS). Technically HTTPS is simply an extension from HTTP for knowing/using TLS.
You can read up online to get more details. To help clear up some potential nuances on that information journey, know that an SSL certificate is really (now) a TLS certificate. That is because there was a deprecation; so now we use TLS (instead of SSL) and there are new versions issued thereof. Although, we all tend to use SSL (the previous name) out of habit. To know more about certificates, read up on: CA, CSR, self-signing and wildcard certificates. There are free services like Let’s Encrypt (for non-wildcard). Although, and fortunately , Wix.com provides all this without hassle .
Regarding your question about the browser history. If you are using a REST API type process, then a request is (usually) stored in the browser. That’s why for sensitive information we must add in additional security measures – e.g. for a Log-In the common practice is to use OAuth2.0.
To help further (from my assumption) on what you are looking, any information that is sensitive should be obfuscated and/or encrypted in order to protect your information. Therefore, we first authenticate access via a login (which Wix handles), then subsequent access (within access/allowed session) is safe, for the most part, for transacting without worry to continually encrypt each action – since security would be adding an additional expense, slowing down performance to your users and their experience.
Apply for this purpose.
(it is assumed you are handling normal log-in for typical usage, and not some special usage)
Since the session token provided back (received as JSON) from Wix is only for that user whom you’ve logged in - only that user should be able to gain access. Therefore, on a normal situation (ignoring eavesdropping and malicious actors) you should be fine on that part. Although, when submitting the information to Wix to get the session token, you would be passing sensitive information which is encrypted over HTTPS/TLS but the browser would contain that (source / un-encrypted) information. Again, since normally it is for the same user it can be assumed it is fine. If you do not want that, then look into opening a private browser in the App (mobile-side app iOS/Android) and then clearing the history afterwards.
I’ve also posted this to help more with the coding within Wix.com:
https://www.wix.com/corvid/forum/community-discussion/member-s-login-session-token-help-better-wix-coding-from-lessons-learned
P.S. You may already know this but incase not: Base64 encoding is not encryption but rather a way to read text from a string or conversion from a data type. The size of each character (technically a unit) would take up a data size to reflect the proper or intended encoding. The variations start from ASCII, which is the same size as UTF8.
@embsats
To help other users and can keep things clean for all - I’d suggest to create your own post, with your code so far, and what your exact issue is. Then include/mention me there and I will check it out. Hopefully it is something I can help out with.
@reveel Running across your answer since I was looking for the same thing, accessing Orders collection using http-functions. Would you mind sharing what you find? I tried login using wix-users-backend and that didn’t even give me a sessiontoken. Let alone do applySessionToken
@reveel -
I also have posted a few comments in this forum on this exact topic. See here , for example. As you noted, there is no way to “finalize” the login process programmatically from the back-end.
For me, I assumed that the back-end would allow me to log in, then perform queries, updates etc. through back-end API (important for mobile apps) instead of through web pages. Alas, it does not appear to be set up to do this.
What I have done for now, is use the back-end login() function to merely validate the username/password. Once validated, I use the back-end APIs with their ability to turn off authentication for the data manipulation I need to do. For example:
export async function get_utils(request){
console.log("utils function called");
let response = {"headers": {
"Content-Type": "application/json"
}
};
let options = {
"suppressAuth": true,
"suppressHooks": true
};
let email = "";
const operation = request.path[0]; // ex: "login"
switch (operation) {
case 'memberdata':
response.body = {"result":false}; // Default false
email = request.query["email"];
console.log("Got email argument: " + email);
await wixData.query(<YOUR COLLECTION HERE>)
.eq("email", email)
.find(options)
.then( (results) => {
if (<GOT WHAT YOU WANTED>) {
console.log("Got what we wanted.");
// Now get their _id value so we can search SITConnections
response.body = {"result": true,"usefulinfo" : results.items[0]};
} else {
console.log("Did not get what we wanted for user: " + email);
response.body = {"result": false,
"errormsg" : "data could not be retrieved."};
}
})
.catch( (error) => {
console.log("Got error: " + error);
response.body = {"result": false,"errormsg" : error.message};
});
return ok(response);
}
Note the use of async/await. This allows me to utilize Volley to make the HTTPS threaded request, which will only return once the activity is completed.
The ‘options’ is set to ignore authentication for the data query. So I have to be careful and only call this AFTER my app has validated the use via the back-end login() API. The good news is that at least that API will validate or throw an error if the wrong credentials are passed. The bad news is that once the back-end returns successfully, I can’t find a way to “log out”. Apparently even though the API is documented that you need to “finish the login” using front-end web page code to call ‘applySessionToken()’ returned in the back-end login() promise, Wix thinks the user is logged in! So we are in some kind of strange “in-between” state - the user is logged in, but can’t do anything since there is no session token “applied”, and there is also no way I’ve found to log them out!
Plus, it just makes me nervous to have back-end functions able to muck around with user data where we aren’t validating on every call.
In contrast, I like the way the DropBox API is written for REST calls. You log in, you get a token, you use that token on every subsequent call until you log out. Very clean.