Access Record data from an html page via API call
I have had a hard time getting accustomed to working with API calls from outside of Quick Base and since I have limited experience with XML. Finally after struggling quite a bit I have come up with a (seemingly) decent method for getting/accessing record data from an API call in an HTML page. I will post the code below and please provide any feedback for this method, I am still early using Quick base API calls. This method uses the option to return the record data as a 2-dimensional array that can be accessed with "qdb_data " where the "x" is the index selector. You can easily check the number of returned records by looking at "qdb_data.length" <head> <script lang="javascript" src="yourdomain/db/ yourtable?a=API_GenResultsTable&query={'field id'.operator.matchvalue}&jsa=1&apptoken=[yourtoken]"> </script> <script> function displayData(){ alert(qdb_data ); }</script> </head> Curious about the security of having the API info and app token within the client-side code. Obviously a QB code page is fairly secure compared to a remote code page but still curious about it. Thanks everyone.
Is there available a general security ""White Paper"" that is a document that describes the site and record security provided by Quickbase?
Is there available a general security "White Paper" that is a document that describes the site and record security provided by Quickbase? Looking for something that gives a general overview of these features
Does QuickBase currently support publicly available two-factor authentication?
Hi, Does QuickBase currently support Google Authenticator or similar publicly available two-factor authentication? If so, how do I turn that on? If not, why not and when will this critical security functionality be available?
Security Concern. Help.
So I recently got an email from Ed Jennings, the CEO, alerting me about an incident where-in one the employee emails was used for a phishing scam. They went into detail about what they did to stop it and what I should do and so on. However... The email they provided to ask further security-related questions, security-awareness@quickbase.com, was deemed no longer valid by my outlook client. Now I'm worried if this email alert itself is fraudulent. And the fact that I do not see any alerts in my admin console for my realm makes me more suspicious. ------------------------------ James Dalton ------------------------------Why ""Password Reset Error""?
I have a user who has forgotten her email. She goes through the "forgot password" procedures, the system sends her an email, and when she clicks on the email, it takes her to a "Password Reset Error" page, with the message "The email link you clicked on to reset your password was expired. For reasons of security, this link expires 90 minutes after QuickBase sends them. You may try to reset your password by pressing the button below." She's tried clicking that button, and it sends a new email, and when she clicks that link, it takes her to the same "Password Reset Error" page. She's on Chrome. I've tried having her clear cookies and cache, but so far, no luck. Any ideas?I'd like to propose addressing the current allowable password length (20 characters).
Our single sign on environment allows up to 48 characters and the current limit should support NIST guidelines (800-63B): Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. [...] Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.
