Demo Access dictated by number of times vs.

[Andy Robo]

Hi

I

[Vaughan]

Hi Andy

Take the plunge and whip up a quick demo file and post it for the experts to crack.

[Andy Robo]

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

[Andy Robo]

Oh hell, how do you add attachments!

Oh like that!

Oh, it's fp7, by the way

[Andy Robo]

Sorry this time

[Andy Robo]

jees... this time

sorry I've got to go have dinner... I'll post it in 1/2 and hour

[Vaughan]

LOL

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

[Andy Robo]

Here, now, is my attachment with my demo...

Andy

open7456.zip

[Reed]

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

[Andy Robo]

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!

Any more ideas following this are still welcome...

Andy

[Reed]

After I changed the username for full access and field access priveleges for the user acct., the file did not open with full access, and I was not able to edit the n_opened field.

[Andy Robo]

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

[BrentHedden]

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.

[Reed]

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

[Andy Robo]

Thanks... that's what happens when you don't test properly eh?

[Andy Robo]

I tried changing the script to run with full access and it works!!!

[Vaughan]

That's why you post stuff here... lots of beta testers!

[Oldfogey]

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.

[Andy Robo]

Agreed on the teacher (How much did you say it cost?:?!!) situation - but...

'scuse my thickness Paul... your reference to an idiotic/endless loop means what exactly?

Andy

[DrRoebuck]

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.

[Oldfogey]

Gee, Josh! How on earth could you do that!?

Another neat rick is to include a Close() in the OnOpen script. Not that I've ever done it, of course.