You can beg all you want, but it still wont make you right or the update_tables.cgi program secure. You didnt try what i suggested about flushing your cookies and going to that page did you?
"The program" is the single executable that is running when you call it by going to its cgi enabled web location. manage_users.cgi is one program and update_tables.cgi is a wholly separate program. Each ends when it sends the html to your browser. If you choose to check login status in manage_users and let anyone execute update_tables because in that program you only check the status of the last person who logged and leave that status in a file then in that is your choice.
You might remember that the "admin access" link is displayed by manage_users which did check the login status, but just because it isnt visible on a manage_users.cgi generated html page as a link (the admin access is not visble to the non-admin user) doesnt mean that http://www.jala-mi.org/httpsdocs/jala_AdminCore.htm doesnt still exist, and that anyone can still go there by knowing its name, and that unless update_tables.cgi properly checks that they are logged in they will be able to execute any of the functions on that page if the last person to login was an admin. You yourself listed that page here, Google crawls this site very frequently, an hour or two after a posting it is searchable in google, google indexed that page over a month ago(Mar 15, 2017), https://www.google.com/search?sclient=psy-ab&site=&source=hp&btnG=Search&q=%22http%3A%2F%2Fwww.jala-mi.org%2Fhttpsdocs%2Fjala_AdminCore.htm%22, so this isnt even a security by obscurity question anymore, you yourself let the cat out of the bag.
I have no "intolerance for doing things in a different manner". I am known for doing that myself. But "a different manner" and a "correct manner" are two separate concepts. Just because it is different it doesnt mean it is still correct.
So i suggest again, Login as user 428, flush your cookies, close your browser, reopen your browser, and goto http://www.jala-mi.org/httpsdocs/jala_AdminCore.htm then try pressing some buttons. You have no cookies to send back, there is no way for update_tables.cgi to tell if you are a valid user or not at that point. All it has is a file left behind by the last person to log in. Try pressing a few buttons and see if you think it is secure. You will see that you were mistaken when you said "the storable module solved my long running problem" but instead it just opened a new can of worms. Now log in as a different user, flush your cookies again, close your browser again, reopen your browser again and go to the same web page. and see what happens when you push the buttons under the authority of the last user to log in. All that the storable file did was record the acesss level of the last user to log in. If you are trying to update your tables and someone logs in that isnt an admin you will be blocked as soon as they finish logging in and the storable file gets written over. You can test this scenario with two different computers, log in as user 428 on one, run an update to see that it works, then on the second computer log in as a different user, say user 427 for example. finish the login process, then see if user 428 can still update tables.
poj made a valuable suggestion at Re^28: global var, i made another at Re^28: global var when i said Have you considered calling manageusers::ProcessLogonRequest($query) in update_tables.cgi but we have all seen that over and over you choose to think you know it all and refuse to consider what you have done is just plain wrong. In this case it is different but not different and correct, but different and wrong. You are the one acting like a snowflake looking for your safe space but not realize you have not made it safe at all. Unless update_tables.cgi properly checks the login status of the user each time it is called the safe space you desire is not safe at all no matter how many times the monks here have tried to show you the errors you have made.
I have been dealing with clueless newbies like you for over 4 decades, i have taught myself how to think like you do and that enables me to quickly realize when you have made a big mistake like you have many times. But while i can lead the horse to the water i still cant make it think.
One thing i have learned over that time is that when someone says "Dont question me I know I did it correctly" without first checking then they are bound to be wrong. My favorite example was when i was incharge of the backend for login at Trintex. People couldnt first-log in after a password file update. There were four phases to the service, the backend ran on Big iron, we communicated to the TPF team, who then communicated to the Series 1 Team who managed the point of presence computers at every node, and they communicated to the TBOL/PAL team that ran on the PCs. So we've got 2 VPs and 5 teams in a meeting trying to figure out whats going wrong, I said i checked the tapes i made, the userid/password pairs were there, and that i had a ZBASE DUMP done that showed they were loaded correctly to TPF (see below). The TBOL/PAL guys said they went over their code and saw no reason to think there was an error in the initial logon procedure. The Series/1 guy said he went over his code too and saw nothing wrong, anyway he just cached what the TPF guys sent him. So we looked at the TPF guy, and he said, "Dont question me I did it correctly, I didnt need to look". Later that day it turns out that besides the new password tape, change-control showed us that there was a change just inserted to the TPF login process a few days before that which was written by that very guy, while he still insisted he was right we got a colleague of his to QC his code and it turns out he badly mangled a binary search, and every 15th new user would never be able to log in. Everyone else tested/checked their code but him, and he was the problem. Wasnt the first time that the first person to blindly say "it isnt my fault" without first checking turned out to be the one at fault either. Doubt it will be the last, but it seems you are the next.
So the operations team there had a bad habit of replaying "use anyway" when the OS complained the tape volser that was mounted was not the one being requested. I had one password tape overwritten in the 2 hours between when i wrote it and the TPF team tried to load it. So i was already regularly getting a ZBASE DUMP run after the TPF folks told me they loaded the tape to make sure. At least the guy that wrote that ZBASE LOAD section learned to check for teltale "magic bytes" i wrote at the start of the tape and would reject an invalid load because the wrong tape was mounted. We all complained that ops was just being lazy in replying "use anyway" but that was useless till after i left. Im up in building 005 in Kingston a year later and i get a call from the development area TPF manager asking if i had any copies of the code i wrote to make the password tapes for the test system. It wasnt a problem making the tapes, the prod programs did just fine for that, it was the list of test area userids that was in those programs they needed. I replied that of course i didnt keep copies, that would be unethical. Well it turns out that rather than take ownership of my disk space as i had suggested, she just told them(OPS) not to delete my userid, which they did about a year after i left anyway, and all the datasets disappeared. And there were no backups left because everyone they looked at containing that data had the wrong VOLSER on it because ops said "use it anyway" when MVS complained the wrong tape was mounted. Turns out that 1/4 of all the backup tapes had been mangled that way too, but all of the ones that had my data were lost. So then OPS was told never to reply "use anyway" after that.
One of the reasons i left was poor security, that password tape had the passwords in the clear, and not just the passwords were in the clear but interesting stuff like credit card numbers were in the clear too, and anyone with ZBASE DUMP authority/permissions could dump that TPF list. Backend regularly did that to get info back from the TPF system too, every week. No matter how much we complained the powers-to-be would not let us encrypt the data. I even complained to the Arthur Andersen guys when they were in to do an audit but it turns out they were told to ignore it or not get paid. So a few years later in need of a short contract im back at Prodigy codeing some reports that had been in the request queue for years, that nobody wanted to do (i finished them all in about 6 months), and i talk to an old buddy who took over userids/login/backend after i left. And he tells me this great story, about being investigated for fraud. Somebody was using credit cards only used on prodigy. My buddy was a good guy, they cleared him quickly, but MC/VISA people were not happy about the lack of encryption at all. Took them about a year to finish that change when it would have taken about a month if we did it from the start but they had to or MC/VISA wasnt going to let them make charges anymore. Mind you this was about 5 years after i left that they finally encrypted. In the meantime they convicted they guy who was using the cards. Turns out he had just changed his name to "Membership Services" and phished people into telling them their passwords because they thought he was a legit employee. Now with their passwords he had access to their credit card numbers, no hacking or dumping involved. He was smart, they had trouble pinning it on him at first, he never had anything sent to his address, always sending big-ticket items to his girlfriends instead. They finally got the gals to roll on him when it was pointed out to them they were not the only girlfriend like they thought but instead just one of about a dozen. They turned states evidence real quick after they found that out.
