Jump to content

Demo Access dictated by number of times vs.


This topic is 6489 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Good idea Vaughan

Ok... so here it is - it has two user's defined - neither of which have passwords for the purposes of this demo

The file is set to open under 'User' (other account is 'Admin') (again - no passwords for either)

The n_opened field is on a non-accessible layer for the User account, scripts set to executable tho'

It should open 4 or 5 times before showing the dialog box, and then close (in a dev solution I'd put an exit application script line)

I haven't put any other security features on it -

give it your best shot!!!

Andy

Link to comment
Share on other sites

LOL

Consider using the EDIT link to edit the original unsuccessful attempt at sending the attachment, rather than making multiple posts. wink.gif

Link to comment
Share on other sites

Well, I cracked your file.... I notice that you didn't define any passwords for either the user or admin account. Although I did not guess this trying to open the file. I simply created an empty database and then created a file reference to your file. Then I added a table occurence to my file from yours. Now when I open my file, yours opens, bypassing the startup script. In this case, it also opened the file with full access since the default full access account in my file is also "Admin" Even after I changed the full access account name, I was still able to open the file bypassing the startup script. I then created my own layout containing your n_opened field where I changed the value to -50000000000. Now I can open the file more than 5 times. This shows that you need to limit access on a field by field basis, not just by not having a field on accessible layouts. Sorry about the rambling explanation, but it's late here and it's my birthday today!

Dana

Link to comment
Share on other sites

Cheers Dana

The lack of passwords was deliberate ( I mentioned in my second post, but will excuse your missing it given how many foobars I posted today) - I will experiment with throwing them in. My most appreciative gasp is a nod in the direction of needing to limit field access; field by field... good thinking.

I wonder - if the full access account was some random string with a password would a new database initiating an occurence to the file still open it as full access?, even if that 'opening file' were opening under full access?

I have had so many random situations opening relational files under v5 & 6, and now it's all a bit diff with 7 that i can never quiet remember what happened.

Thanks for cracking it... the demo is downloaded by teachers' most of whom won't possess your level of hack and crack skill... hopefully!!!!frown.gif

Any more ideas following this are still welcome...

Andy

Link to comment
Share on other sites

Oh, Happy birthday for yesterday by the way Dana...

So I added a random user name and password for my full access account, and restricted access to the n_opened field for the default user account.

2 points under this:

1. I'm not going to tell you the full access name or password

2. I tried calling the file from within another file (using a script) under full access, it seems to only open the original file under the User (restricted) account - but I may not have tried hard enough...

the added attachment features my changes

Andy

open7456.zip

Link to comment
Share on other sites

Something else that couldn't hurt and that I've used in my solutions before - Add the script step Allow User Abort [Off] Especially when it comes to passwords or something simular where I want to make sure that the script performs.

Link to comment
Share on other sites

This seems to now be locked down pretty well, but now the script doesn't seem to increment the n_opened field. I gather this from the fact that I can open it more than 5 times. Perhaps your startup script cannot increment the field when the user is logged in with only user privileges, since the user has no access to the field. You could fix this by allowing the startup script to run with full access. (A checkbox in the script definition)

Dana

Link to comment
Share on other sites

Andy,

I think you are a bit optimistic. My (lengthy) experience with teachers is that they are the greatest code-crackers around, if it means getting something for free. Anyone who has ever written an idiotic (eg endless loop) OnOpen script will know Dana's trick.

Link to comment
Share on other sites

  • 2 weeks later...

That would be the fine art of putting some erroneous loop into an OnOpen script, which would be triggered when the database was opened. Because the db went right to the loop, you'd be essentially locked out of your own db, regardless of access privileges.

I speak from experience.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.