2010/2/10 Richard Gaskin <[email protected]>: > With v4, the engine now uses a more secure method to secure scripts, but in > my testing it has also removed any way to determine when a stack is > password-protected without using "try". > > In versions prior to v4, you could do this: > > if the password <> the passkey then ... > > The password and passkey returned an encrypted string which, while > meaningless to the human reader, would at least allow comparisons of the > password and passkey to determine if the passkey had been set in the current > session, or if there is no password at all. > > In v4 and later, asking for the password or passkey returns simply "true", > which might be sufficient but here's the rub: > > If you start a new session with a locked stack, asking for the password will > return "true" which is correct, but asking for the passkey will also return > "true" which is incorrect, since no passkey has yet been entered. > > I would expect that asking for the passkey of a stack that has a password > would return "false" until a passkey has been entered in the current > session. > > > I discovered this with stacks in which the password had been set in a > previous version, but I just confirmed it in v4 using this recipe: > > 1. Make a new stack > 2. Set the stack's password > 3. Run this in the Message Box: > > put the password of this stack && the passkey of this stack > > You'll get "true true", which is appropriate because the stack's password > was set in this current session and therefore its script is available. > > So now continue this test: > > 4. Save your stack and quit > 5. Re-launch Rev, and re-open the stack > 6. Run that command again in the Message Box > > RESULT: "true true", which seems inappropriate because the passkey has not > been set and the stack's script cannot be accessed until it has. > > > So this leads me to two questions: > > 1. Can anyone here spare a moment to confirm this behavior, and does it seem > inappropriate to you?
I have follow all your steps and I can confirm that I obtained the same results as you. Inappropriate... Yes and no. That the function returns true when the passkey is empty, this seems odd. Now I think that for safety, less informations you have the better is it. What it seems inappropriate to me is that when you set the wrong passkey, you obtain an error. I imagine already someone creating a loop that would try a password as if it gets an error message. In my opinion I believe that no message should be returned at any time. If the password is good, it decrypts the stack and no more. It's reminded me a story with my habitual development tool (no no it's not RR, unfortunately ;)) which shall remain nameless for not voluntarily give bad idea... A few years ago, a client showed me how he was satisfied with the new encryption system of this tool. It is true that in previous versions, retrieve the password was a formality. He was very happy with the feature that permitted to save a password shortcut. This shortcut allowed users to connect to the server without entering the user password... The idea seems already strange to save a shortcut password in a file accessible to everyone ... In addition, although internally encrypted in the server, I discovered that the password was saved in clear text in the shortcut... Regards, -- -Zryip TheSlug- wish you the best! 8) http://www.aslugontheroad.co.cc _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
