in reply to Re^15: global var
in thread global var
IN the code that does show that $LoggedOn_user_id is not exported by manageusrs. put this in right after your use manageusers qw($LoggedOn_user_id); statement
and see what your error log says. Be careful to cut and past all of that code, right click on download and select save file as and cut it all from that file you downloaded. Then do it in your sample program above too, and compare the warnings you get from both, remember order in the error log matters! Cut and paste the warnings from both the sample and the real program back here.{ use strict; use warnings; my %wanted; $wanted{manageusers}=1; for my $inc (@INC) { opendir (my $dh,$inc) || warn "Can't opendir $inc: $!"; while (my $file=readdir $dh) { if ($file=~m/(.*)[.]pm$/) { if ($wanted{$1}) { warn 'found:'.$inc.'/'.$file; } } } closedir $dh; } }
and saying And later I populate the variable with the desired data is easy, proving it is not as easy. So cut and paste ALL of manageusers::OpenConnection() and ALL of every subroutine it calls to prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^17: global var
by tultalk (Monk) on Apr 11, 2017 at 18:09 UTC | |
Test Program Error Log
Real Program Error log: found:/home/jalamior/www/httpsdocs/cgi-bin/lib/perl/manageusers.pm at update_tables-development.cgi line 41. Tue Apr 11 11:26:22 2017 update_tables-development.cgi: found:/home/jalamior/www/httpsdocs/cgi-bin/lib/perl/manageusers.pm at update_tables-development.cgi line 41. Can't opendir /usr/local/apache/lib/perl: No such file or directory at update_tables-development.cgi line 38. Tue Apr 11 11:26:22 2017 update_tables-development.cgi: Can't opendir /usr/local/apache/lib/perl: No such file or directory at update_tables-development.cgi line 38.
You say: and saying And later I populate the variable with the desired data is easy, proving it is not as easy. So cut and paste ALL of manageusers::OpenConnection() and ALL of every subroutine it calls to prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else. I don't understand the question. Search all fdiles on manageusers::OpenConnection(); yields 10 hits.
They all call the same function
You say: prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else It is oly populated at two places. For a new logged on user it gets the id from the session table. For an already logged on user (cookie expires 7 days) it get the ID from the session table based on the SID lookup.
| [reply] [d/l] [select] |
by huck (Prior) on Apr 11, 2017 at 18:33 UTC | |
are those log messages from both the one that was failing and the one that worked? its hard to tell IF the only thing you call in the working example is manageusers::OpenConnection() then why you you expect $manageusers::LoggedOn_user_id to be anything but zero? So You have yet to prove that you are actually setting $manageusers::LoggedOn_user_id by code that is being run anywhere. Show us all of the subroutines that contain the following code and any subroutines they call In particular where $uid gets set before you run $LoggedOn_user_id = $uid;. and i can become any user i want to be by manipulating the user_id parm i send back to you, that doesnt seem very secure does it? It is easy to create code that sends back any value i want in the user_id field | [reply] [d/l] [select] |
by tultalk (Monk) on Apr 11, 2017 at 20:14 UTC | |
are those log messages from both the one that was failing and the one that worked? its hard to tell. The one that failed. No log from the one that worked . Ran in Padre and can't find log. "You have yet to prove that you are actually setting $manageusers::LoggedOn_user_id by code that is being run anywhere." The rwo code blocks above do exactly that. Entire code at end Filled with comments
You say: In particular where $uid gets set before you run $LoggedOn_user_id = $uid; . $uid is popuated earlier in processing a new logon. "and i can become any user i want to be by manipulating the user_id parm i send back to you, that doesn't seem very secure does it? It is easy to create code that sends back any value i want in the user_id field" That makes no sense to me. When a legitimate user tries to log in, the username and password are encrypted and sent back for comparison to the username/password from the database as encrypted by the same algorithm on the server.
| [reply] [d/l] [select] |
by huck (Prior) on Apr 11, 2017 at 23:44 UTC | |
by tultalk (Monk) on Apr 19, 2017 at 02:28 UTC | |
by tultalk (Monk) on Apr 20, 2017 at 22:42 UTC | |
|
Re^17: global var
by Anonymous Monk on Apr 11, 2017 at 21:16 UTC | |
This is how you write that shorter and better
| [reply] [d/l] |
by huck (Prior) on Apr 11, 2017 at 21:51 UTC | |
No it isnt, notice i didnt stop when i found it, like use/require does. | [reply] |
by Anonymous Monk on Apr 11, 2017 at 22:33 UTC | |
No it isnt, notice i didnt stop when i found it, like use/require does. Why is that important? use/require only load one file | [reply] |
by huck (Prior) on Apr 11, 2017 at 22:59 UTC | |
by Anonymous Monk on Apr 12, 2017 at 00:06 UTC | |
| |