Prevent a stack from opening

[oldummy]

I have two stacks. Stack one writes file "blah" when a certain condition is met"

All of this works fine:

open file 'blah' for write
write "123" to file "blah"
close file "blah"
go stack "two"


In my openstack handler in stack"two"I have this:

On openstack
if there is a file "blah" then
pass openstack
else
close this stack
end openstack

all of this works great in the dev environment. When I try to open stack"two" it tries to open and then it shuts down immediately.
When I build it, I can just open stack two without going through stack one. which is exactly the thing I am trying to prevent.
any ideas?

[oldummy]

I forgot to mention they bot reside in the same folder.

[richmond62]

I assume one of those stacks is a substack of the other one . . .

[dunbarx]

oldDummy.

Change the name of your stacks and try again. It may be that you have broken a cardinal rule by naming your stacks with a number. Never do that, especially when dealing with controls. And you may not be able to get away with using "two" as opposed to using "2", since LC reserves the words for the first ten numbers and probably sees "two" explicitly as "2" anyway.

Let us know if this helps.

Craig

[Klaus]

Hi oldDummy,

why not let stack "one" take over control?

Code: Select all

...
## I prefer the shorter URL syntax:
if your_condition_is_met then
   put "123" into url("file:bla")
ELSE
## file NOT written
   go stack "two"
end if
...

Best

Klaus

[oldummy]

They are not main and substack.
They are two separate stacks that work well until I build the first stack with the second stack just a stackfile.

Before the build, I cannot open the second stack, as it looks for that file"blag" and doesn't find and quits.
After the build, anyone with livecode installed can just open the second stack.

The stacks have names other than numbers, I was just using one and two.
I have a reason for not setting a password for the second stack.
The second stack has info in it such that I would want it to be just simple to open.

Again , like so many things, it works in the ide, just not after the build.
The reall y strange thing is I feel certain it was working either way before.

[stam]

I have two stacks. Stack one writes file "blah" when a certain condition is met"

All of this works fine:

Code: Select all

open file 'blah' for write
write "123" to file "blah"
close file "blah"
go stack "two"

In my openstack handler in stack"two"I have this:

Code: Select all

On openstack
   if there is a file "blah" then
   pass openstack
else
   close this stack
end openstack

all of this works great in the dev environment. When I try to open stack"two" it tries to open and then it shuts down immediately.
When I build it, I can just open stack two without going through stack one. which is exactly the thing I am trying to prevent.
any ideas?

Can I ask what the intention is here?

Are you trying to allow the system to only open stack "two" if you've opened stack "one" first, and are writing a file from stack "one" to prove that's happened? Or is the purpose something different?

If that is the case I would recommend a different method for doing this, rather than writing a file to the filesystem.
If not please do clarify because a different workflow may be better.

In all cases, I would probably want to ensure file references are correct - where are you writing file "blah"?
(also keeping in mind that many OS's can be very picky about where you write files to).


Stam

PS: I've put the [ code] tags in your text when quoting you - please ensure you do this when you post code, it makes everyone's life easier... (it's the 5th button from the left, starting from the bold text button - just select the text you write or copy/paste and it will insert the tags for you)

[oldummy]

I'm sorry about not posting the correct way. I simply forgot to.

The second stack has no password, or rather it's password changes each time I open it. The password is built through a fairly complex process in stack 1, and can be determined by reading a file there in the correct manner. So there is no password to be hacked.
Everything works good now. I was lucky to have the stack's predecessor on hand. The second stack on it was protected in the same manner.
It was in a preopenstack handler. Apparently I moved it to the openstack handler while fooling with it.

Code: Select all

on preopenstack
   if there is not a file "blah" then close this stack
end preopenstack

Built it again, and now cannot open the stack with the sensitive information without going through the process in the first stack.
Which is what I wanted.

Thanks for your help.

[oldummy]

I have one last question concerning this.

How secure is stack that "supposedly" can not be opened without another stack involved? The stack that I am trying to secure is password protected and the scripts cannot be read without de-encrypting them.

The first stack asks for a password, so you cannot even start the process of creating the password to get to the second stack.

Am I wrong, or rather how wrong am I in assuming I have a secure second stack?

[stam]

I have one last question concerning this.

How secure is stack that "supposedly" can not be opened without another stack involved? The stack that I am trying to secure is password protected and the scripts cannot be read without de-encrypting them.

The first stack asks for a password, so you cannot even start the process of creating the password to get to the second stack.

Am I wrong, or rather how wrong am I in assuming I have a secure second stack?

As long as both stacks are password protected that's safer. Never 100% though.
For that reason the usual advice is to not store the password itself in the stack, but a hash of the password.

The reason I asked about the file, is that too is a security issue. What is to stop someone from copying its contents..?

Instead, what I would have done (assuming the app is meant to be built as a standalone, not run from the IDE normally) is declare a global variable in both stacks - let's call it gBlah since you went with "blah" for your filename.

before the script that generates the file declare the global:

Code: Select all

global gBlah
put "123" into gBlah
go stack "two"

in stack "two":

Code: Select all

global gBlah
on preopenstack
  if gBlah is empty then close this stack
end preopenstack

presumably you process the contents of the file - do the same with the global variable and when done (and when you would normally delete the file you created) just put empty into gBlah.

I'm pretty sure this is better and safer than generating a file... but that just my $0.02...

[FourthWorld]

The second stack has no password, or rather it's password changes each time I open it. The password is built through a fairly complex process in stack 1, and can be determined by reading a file there in the correct manner. So there is no password to be hacked.
Everything works good now. I was lucky to have the stack's predecessor on hand. The second stack on it was protected in the same manner.

Data security has many levels, each with its own trade-offs.

To provide the best guidance for your case, please help us understand the scope of risk by letting us know which of these threat priority levels best describes the data needing protection.

This data contains:
1. nuclear secrets
2. public facilities security operations
3. health records
4. bank records
5. trade secrets
6. business plans
7. vacation photos
8. picks for next week's pony race at Santa Anita

These are lighthearted, but intended to offer at least a rough estimate of threat severity, so we can siftt through the many options LC offers to arrive at the best fit.

[oldummy]

Well, I would have to say number 1. It is my password manager, and I preferred not to have it's password stored anywhere. So stack 1, through several steps, creates the password that will send me to the stack with all of my accounts/passwords. The actual stack with all of my info has no password to store. It is only password encrypted.
Which is why I am concerned as to how secure is a password encrypted stack. I do use another open source password manager, but this one was a lot of fun to build.

[FourthWorld]

Do you encrypt your hard drive?

[oldummy]

I do not encrypt the hd.
I just realized the my question is only this:
can stack encryption alone be enough to secure the info in the stack, as the only security is the access to the stack.

[FourthWorld]

can stack encryption alone be enough to secure the info in the stack, as the only security is the access to the stack.

I don't know the current script encryption algorithm, but historically it was not as strong as some of the options now included with the encrypt command, which the devs usually recommended for sensitive data.