Is there a way to password protect a page?

What 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?

The 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?

Was there ever a resolution to this?

I 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.

My 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.

Technically, that could be considered a Portal and may violate your Terms of Service. Tread lightly.

No, 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.

Blake, 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.

Again... the lock is for logged in users for pages created to Manage data that was entered via public forms.

And yes, Mark... just one code. Not individual codes for everyone.

OK, so for my app, I actually set it up with a hidden table of users.  There is a button on the dashboard that the user clicks (It is actually on a mini report as I needed to use formuals), which either takes the user to their own userid record on a table of users (in edit mode), or else creates a userid record on a hidden table of users.

That way each individual user sets their own timer.  I have a relationship to my details table based on a reference field of [Current User]  -  formula of 
User()

As I think about it, it's really something only Quickbase will be able to resolve in a feature. The users are already logged in, and everyone logged in is allowed to see the dashboard. However, the URL could be exposed. It's not really private information that would violate any of our company's compliance policies, but it would be a great enhancement to the product. They could further enhance it with your 'temporary password' scenario. Thank you for your suggestions!

Well, the URL can always be accessed if the page is open to EOTI, sort of regardless.

But to the OP's 4-year-old use case, if the page to 'protect' is a report, there's a very easy trick - add a 'filter' field to your table, set it to a certain value by default, and direct the user to a report page that's filtered by that field. They have to enter the 'password' as the filter to be able to view matching records (which are all of them).