Forum Discussion
- ArchiveUserQrew CaptainWhat type of page are you trying to protect? Is it a report, or a Form, or a Dashboard page?
And is requiring them to be logged into QuickBase enough of password protection, or is there a reason to have a different password for this particular page? - AlexandraAlexanQrew MemberThe page is a regular Dashboard page that includes a search option that queries a database of names and returns options to the user. The page will be used by users that don't necessarily have QuickBase accounts, so they would be visiting the page independently of logging into QuickBase, which is why logging in isn't enough. Does that help?
- KellyBianchiQrew Assistant CaptainWas there ever a resolution to this?
- QuickBaseCoachDQrew CaptainI have an app which it contains pay rates and I'm always nervous about those kind of apps. Quick Base is secure, but what if a manager leaves their userid signed on in a meeting room, for example, even if they were using a different App. So much for security.
So in our case we had each user need to enter a secret code to a table on the dashboard of the app and that gave access for 30 minutes.
So you could do the same thing.
Set up a single record with Record ID# = 1 and then have a field that needs to be entered with the secret code. Then calculate if the code is correct and the Date Last Modified is within the last X minutes as a formula checkbox called [Allowed to View]. Lookup that checkbox field to the detail records on the dashboard via a reference field like
[Link to control record (=1)] which is a formula numeric formula of 1.
Then set permissions that certain Roles may only see detail, records where that [Allowed to view] is checked.
So basically you enter the secret code and get say 10 minutes of use.
My setup was a bit different so you would probably have to have a form rule "when the record is saved" to update a date/time stamp field to the current date time when the record is saved (to ensure that the record was updated) and to copy across the secret code field to another field hidden field and blank out the data entry secret code field. - KellyBianchiQrew Assistant CaptainMy situation is simply that, I am using forms open to 'everyone on the Internet' to collect data, and also use the data to email customers with information from their account. This information is organized into a dashboard page for logged in users to manage, but because it has to have public privileges in order to collect and display the data, then I am concerned that the Management page may be exposed with everyone's data. It's not highly sensitive information, but it would be nice to be able to have pages that we could lock.
- ArchiveUserQrew CaptainTechnically, that could be considered a Portal and may violate your Terms of Service. Tread lightly.
- KellyBianchiQrew Assistant CaptainNo, it would be accessible only to logged in users. I've already spoken to Quickbase about our use. The 'everyone on the internet' feature is theirs, and you are allowed to collect and display data to non-users. Managing data is a logged in user function. If anything, this helps to draw the line in the sand.
- QuickBaseCoachDQrew CaptainBlake, good point, and I suppose that one would need to ask to be 100% sure.
But I think that because the information once you get in is the same for everyone on the internet, Quick Base will be OK with it. It is when the information is different per EOTI "user" that we cross the line to violating on the Terms of Service. But as I said, good point. - KellyBianchiQrew Assistant CaptainAgain... the lock is for logged in users for pages created to Manage data that was entered via public forms.
- KellyBianchiQrew Assistant CaptainAnd yes, Mark... just one code. Not individual codes for everyone.