Re^27: global var

Replies are listed 'Best First'.
Re^28: global var by huck (Prior) on Apr 24, 2017 at 20:43 UTC
I have never had such a problem in other languages For some reason i doubt that. If you call a c program that starts another program via a system call do you expect the second program to have access to the variables of the first program. when you say `MyIFrame.src = "https://www.jala-mi.org/httpsdocs/cgi-bin/update_table +s.cgi?action=" + MySource;` [download] you are starting a whole new perl instance, with the script called update_tables.cgi. All the data associated with the perl instance that sent http://www.jala-mi.org/httpsdocs/jala_AdminCore.htm to the browser has been lost if not stored somewhere else like a sessions table because that instance ended when it sent that page to your browser. This is true in c or python as well as you would know if you were a c or python programmer. This is simple cgi programming protocol. So like any other cgi program update_tables.cgi needs to check its cookies and load its session object to find out data associated with the users session. User with 7 day cookie set goes to log on. Cookie recovered, session checked against session database to verify user. User_id recovered from session and stored in LoggedOn_uder_id , then forgotten when jala_AdminCore.htm is sent to the browser and that perl program terminates so it can no longer to be accessed in update_tables.cgi to access other data from database which uses the id as key unless update_tables.cgi checks its cookies and loads the proper session object to get the user id from it Recovering the id from session in the other modules would just be redundant No it isnt redundant, since that is the only place the new perl instance can access the stored user level data. Have you considered calling manageusers::ProcessLogonRequest($query) in update_tables.cgi? That would then process the cookie, lookup the session and set the userid. all you have shown us is that you call manageusers::OpenConnection() and that doesnt do anything with cookies or sessions	[reply] [d/l]
Re^29: global var by tultalk (Monk) on Apr 25, 2017 at 12:24 UTC
For some reason i doubt that. If you call a c program that starts another program via a system call do you expect the second program to have access to the variables of the first program. when you say I did not say I did. I have done that by passing a variable to the new program I don't consider the cgi scripts and associated modules as "different programs" That aside, it is working perfectly using Storable So like any other cgi program update_tables.cgi needs to check its cookies and load its session object to find out data associated with the users session. I could have done that but chose another way I do appreciate the assistance from you and others in the monks I am sorry that I did not make myself clear but I thought my repeated references to and interface between units (modules)was defining. I don't understand how you can say all I have shown you is open connection: I have repeatedly posted sub Main { my $action = $query->param('action'); { #warn("Request for LoginForm manage_users.cgi: '$action'"); ($action eq "getloginform") && do { manageusers::OpenConnection(); #warn("Just before ProcessLoginRequest - create session = '$qu +ery'"); my ($result,$message0,$message1,$message2) = ProcessLoginReque +st($query); warn("result = '$result' message0 = '$message0' message1 = + '$message1' message2 = '$message2'"); if(!$result){ #warn("Tell client that login failed"); manageusers::CloseConnection(); LoginUserFailedForm("The Login Request failed due to some i +nternal errot. Please try again or contact the office."); exit(0); #return; #exit; } elsif ($result == 1) { warn("Already logged in so send client already logged in for +m This is in the initial action GetLoginForm"); manageusers::CloseConnection(); CreateAlreadyLoggedinForm($message0); exit (0); #return; } elsif ($result == 2){ #warn("Not logged in so send client login form"); manageusers::CloseConnection(); CreateLoginForm($message0, $message1, $message2); exit(0); #return; #exit; } }; [download] and sub ProcessLoginRequest { my ($query) = @_; my $status = 0; my $sid = GetUserSessionCookie(); # warn("ProcessLoginRequest Query: '$query'"); # warn("ProcessLoginRequest SID from cookie: '$sid'"); #Check if it got valid return from fetch cookie if ($sid ne 0){ $status = 1; } #or, check if valid return from cgi query elsif($query){ # if (exists $query{$sessionname}){ $sid = $query->param($sessionname); if ($sid){ #warn("ProcessLogin Request SID from Query: '$sid'"); $status = 1; } else{ $sid = undef; $status = 2; } } else { #Set up for creating a new session $sid = undef; $status = 2; } warn("SID befor new session : '$sid'"); $session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh}); #warn("session = '$session'"); OpenSession($dbh,$sid); $session->param("#<expires>#",0); $session->param("isloggedin",0); $session->flush(); $sid = $session->id(); #warn("ProcessLogin Request SID from from session create: '$sid'"); my $sessiondata1 = $sid; #id created by CGI::Session; [download]	[reply] [d/l] [select]
Re^30: global var by huck (Prior) on Apr 25, 2017 at 14:49 UTC
I don't understand how you can say all I have shown you is open connection: I have repeatedly posted That doesnt look like this (Re^15: global var) at all does it? `my $dbh = manageusers::OpenConnection(); warn("update_tables.cgi after open connection"); # Dispatch to proper action based on user selection my $count = 0; my $query = new CGI; my $cgiURL = CGI::url(); my $action = lc ($query->param('action')); my $userid_1 = 0; ############################################################### $userid_1 = $manageusers::LoggedOn_user_id; <-------------------------` [download] It is clear you are still unaware of what is actually going on. So which program are you talking about? the one that calls main/logon or the one that identifies itself as update_tables.cgi and doesnt? It seems to you they are both the same program but they are not. I did not say I did. I have done that by passing a variable to the new program Yes you did say that. You say you expect a new program to remember the state of a previously terminated program. So how do you think you pass a parameter to a cgi program? via cookies and sessions or form params of course. I don't consider the cgi scripts and associated modules as "different programs" Each cgi script is its own standalone program started from scratch each time the browser goes to that page, no matter if it is by clicking on a link and changing the address bar address or executing something like `MyIFrame.src = "https://www.jala-mi.org/httpsdocs/cgi-bin/update_tables.cgi?action=" + MySource;` When you executed that you started a new program, from scratch but it is perfectly clear you still dont understand that. I had thought you got that clue when you were complaining that update_tables.cgi took over the whole page when you started it via `self.location='https://www.jala-mi.org/httpsdocs/cgi-bin/update_tables-development.cgi?action=updatetable_3'` and we showed you why that was the problem That aside, it is working perfectly using Storable ... I could have done that but chose another way So one user logs in as admin, and then *any one* that tries to go to http://www.jala-mi.org/httpsdocs/jala_AdminCore.htm will have admin rights to do whatever they want because the storable file is still around. Or you go thru login, then another person goes thru login which then changes the storable file and now you cant access update_tables.cgi anymore. I guess to you that is working perfectly, its just clear you still dont understand the async nature of cgi programs and how web pages work. Login, then try flushing your cookies and close your browser. then open a new browser and go to the admincore page and try pressing a few buttons, is that how you want things to work? with no cookies and a new browser session you cant be logged in, right? So now do you get it that until the next person logs in anyone that goes to the admincore page will have admin rights?	[reply] [d/l] [select]
Re^30: global var by shmem (Chancellor) on Apr 25, 2017 at 16:03 UTC
At this point, and at that level of dicussion: If I was you, I would hire somebody (or ask for a volunteer) that does the code review with me and reads manual pages for me, so I can learn something - I guess, maybe I wouldn't either. At least I would make the whole blob available somewhere, maybe some kind soul wants to sort that out. But I could be uneasy about it, and again, wouldn't do that, either. So, sorry for now. If I have spare time, I might re-read that thread and annotate tersely what parts of the perl documentation and which RFCs need to be read. But that could take some ten years. Maybe it's done earlier, or not at all. perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply]
Re^31: global var by huck (Prior) on Apr 25, 2017 at 16:35 UTC
Re^32: global var by tultalk (Monk) on Apr 26, 2017 at 01:03 UTC
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^28: global var by poj (Abbot) on Apr 25, 2017 at 17:50 UTC
Recovering the id from session in the other modules would just be redundant If you add a subroutine into `manageusers.pm` like this `sub getLoggedOn_user_id { my ($dbh,$query) = @_; my $session = CGI::Session->load( "driver:MySQL", $query, { Handle => $dbh } ); return $session->param("user_id"); }` [download] then only change in your script is from `$userid_1 = $manageusers::LoggedOn_user_id;` to `$userid_1 = manageusers::getLoggedOn_user_id($dbh,$q);` One less 'global' to worry about poj	[reply] [d/l] [select]