Menu
▾
▴
openinteract-help
|
From: Bernie L. <Ber...@nt...> - 2002-03-05 00:22:14
|
Many thanks for your prompt responses regarding my problems yesterday. The new release seems to have done the trick. However, I have now reached another stumbling block. The web site is up (using defaults -except see below - and template web site) and I can login as the superuser and/or create a new user (using "create one" in the Login box). The "user - new" link gives me (as superuser) Error Sorry, you do not have access to create a new user object. Returning to listing. Anything that should allow me to do anything interesting, e.g. Page actions, results in a "Task is Forbidden" message (as superuser). The only changes I have made to the defaults are: . use postgresql instead of mysql . change the Apache listener to 81/8081, because if I leave them at the default of 80/8080 httpd-perl runs, but httpd doesn't run, with errors saying it can't start because port 80 is already in use. Any ideas where I should start to look? Regards, Bernie. |
|
From: Chris W. <ch...@cw...> - 2002-03-05 03:56:28
|
On Mon, 2002-03-04 at 19:26, Bernie Ledwick wrote:
> Many thanks for your prompt responses regarding my problems yesterday. The
> new release seems to have done the trick.
Good news!
> However, I have now reached another stumbling block. The web site is up
> (using defaults -except see below - and template web site) and I can login
> as the superuser and/or create a new user (using "create one" in the Login
> box).
>
> The "user - new" link gives me (as superuser)
>
> Error
>
> Sorry, you do not have access to create a new user object. Returning to
> listing.
>
> Anything that should allow me to do anything interesting, e.g. Page actions,
> results in a "Task is Forbidden" message (as superuser).
Interesting. What happens if you run the following query in psql:
SELECT class, scope, scope_id, security_level
FROM sys_security WHERE class like '%Handler%'
Also, see what uid the superuser is:
SELECT user_id FROM sys_user WHERE login_name = 'superuser'
It could be that the superuser doesn't have the ID that OI expects,
normally '1'. If not, you can change this in the server configuration
under the 'default_objects.superuser' key.
> The only changes I have made to the defaults are:
>
> . use postgresql instead of mysql
Did you modify the various SPOPS definitions to use SPOPS::DBI::Pg
rather than SPOPS::DBI::MySQL? You should be able to accomplish this all
at once by doing:
$ oi_manage change_spops_driver \
--website_dir=/path/to/mysite \
--driver=SPOPS::DBI::Pg
> . change the Apache listener to 81/8081, because if I leave them at the
> default of 80/8080 httpd-perl runs, but httpd doesn't run, with errors saying
> it can't start because port 80 is already in use.
Sounds like you've got another webserver running somewhere. This isn't a
big deal.
See how the security stuff above pans out. Hopefully one of those items
will get a hit.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: Chris W. <ch...@cw...> - 2002-03-05 14:51:38
|
On Tue, 2002-03-05 at 02:14, Bernie Ledwick wrote:
> Chris,
>
> I think there is another virtual host defined on port 80. I'll investigate
> that later!
>
> I have already changed the driver as suggested. I guess nothing would work if
> I hadn't.
Actually, everything should still work except for creating new objects.
Thanks to DBI, the database-specific drivers don't have much code in
them at all -- mostly just the various auto-increment schemes.
> The sql output is below.
>
> bltest=# SELECT class, scope, scope_id, security_level
> bltest-# FROM sys_security WHERE class like '%Handler%';
> class | scope | scope_id | security_level
> ---------------------------------+-------+----------+----------------
> bltest::Handler::Package | g | 3 | 8
> bltest::Handler::Error | w | world | 4
> ....
> bltest=# SELECT user_id FROM sys_user WHERE login_name = 'superuser';
> user_id
> ---------
> 1
> (1 row)
This all looks ok. So it's time for more debugging. Try running the
following script:
----------
#!/usr/bin/perl
use strict;
use OpenInteract::Startup;
my $HANDLER = 'MySite::Handler::User';
{
my $R = OpenInteract::Startup->setup_static_environment_options(
undef, {}, { temp_lib => 'lazy' } );
my $superuser_id = $R->CONFIG->{default_objects}{superuser};
# Play with the next two lines to experiment
my $superuser = $R->user->fetch( $superuser_id,
{ skip_security => 1 });
$R->{auth}{user} = $superuser;
$R->CONFIG->{DEBUG} = 2;
my $level = $R->user->check_security({
class => $HANDLER,
object_id => '0' });
print "Level: [$level]\n";
}
----------
Subtitute whatever you want for $HANDLER, and modify the user fetched or
don't fetch a user at all. See what comes up for the level and if any
helpful debugging messages pop up.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: Bernie L. <Ber...@nt...> - 2002-03-06 22:44:53
|
Chris,
Tried your perl debug, but not sure what it means.
Output is below.
Regards,
Bernie.
bash-2.05$ perl /tmp/bl.pl
Using (/home/oi/bltest) for 'website_dir'.
superuser_id: 1
Level: [8]
bash-2.05$ cat /tmp/bl/pl
#!/usr/bin/perl
use strict;
use OpenInteract::Startup;
my $HANDLER = 'bltest::Handler::superuser';
{
my $R = OpenInteract::Startup->setup_static_environment_options(
undef, {}, { temp_lib => 'lazy' } );
# my $superuser_id =
$R->CONFIG->{default_objects}{superuser};
my $superuser_id = 1;
print "superuser_id: $superuser_id\n";
# Play with the next two lines to experiment
my $superuser = $R->user->fetch( $superuser_id,
{ skip_security => 1 });
$R->{auth}{user} = $superuser;
$R->CONFIG->{DEBUG} = 2;
my $level = $R->user->check_security({
class => $HANDLER,
object_id => '0' });
print "Level: [$level]\n";
}
|
|
From: Chris W. <ch...@cw...> - 2002-03-07 04:41:38
|
On Wed, 2002-03-06 at 17:49, Bernie Ledwick wrote: > Chris, > > Tried your perl debug, but not sure what it means. > > Output is below. > > Regards, > > Bernie. > > bash-2.05$ perl /tmp/bl.pl > Using (/home/oi/bltest) for 'website_dir'. > superuser_id: 1 > Level: [8] > #bash-2.05$ cat /tmp/bl/pl > #!/usr/bin/perl > > use strict; > use OpenInteract::Startup; > > my $HANDLER = 'bltest::Handler::superuser'; Is this handler name correct? That is, is there a handler class in your site in a file called 'superuser.pm'? The handler should be set to a class in your site which acts as a handler. In your case, the following should work: my $HANDLER = 'bltest::Handler::User'; The reason being that if you set $HANDLER to something not in the system then it's not so instructive when you change the user ID we're fetching to something that is not the superuser. Anyway, the only other thing I can think of is to ensure in the website you're actually logged in as the superuser. You should be able to see a line in your error log like: OpenInteract::Auth::user (33) >> User found: superuser near the top of the entries for a particular request. Make sure you check the log for the exact request you're having problems with. This could be an issue where your cookie isn't set properly, is expiring or is somehow corrupt. I've had the corrupted cookie problem when running OI on Win2000 with the Apache::Cookie module and either Netscape or IE (can't remember which). Using CGI::Cookie fixed it right up. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Bernie L. <Ber...@nt...> - 2002-03-07 08:20:14
|
Chris, I see, said the blindman - or at least I'm starting to! 1. I didn't realise you had private apache log files. 2. Your documentation needs to specify to chown the error directory to "nobody" as well as all the others (html/cache/overflow/uploads). (Incidentally on my platform - Mandrake - the user is apache.) 3. I don't seem to have the superuser.pm you mention: bash-2.05$ pwd /home/oi/bltest bash-2.05$ find . -name "*ser.pm" ./pkg/base_user-1.49/bltest/Handler/User.pm ./pkg/base_user-1.49/bltest/Handler/NewUser.pm ./tmplib/bltest/Handler/User.pm ./tmplib/bltest/Handler/NewUser.pm ./tmplib/OpenInteract/User.pm ./tmplib/OpenInteract/Error/User.pm ./tmplib/OpenInteract/SQLInstall/User.pm ./tmplib/OpenInteract/Handler/User.pm ./tmplib/OpenInteract/Handler/NewUser.pm bash-2.05$ 4. I changed the Handler as you suggested, but still only get: superuser_id: 1 Level: [8] However, know I know about the log files, I'll do some more digging and let you know what I find. Regards, Bernie. On Thursday 07 March 2002 5:12 am, Chris Winters wrote: > On Wed, 2002-03-06 at 17:49, Bernie Ledwick wrote: > > Chris, > > > > Tried your perl debug, but not sure what it means. > > > > Output is below. > > > > Regards, > > > > Bernie. > > > > bash-2.05$ perl /tmp/bl.pl > > Using (/home/oi/bltest) for 'website_dir'. > > superuser_id: 1 > > Level: [8] > > #bash-2.05$ cat /tmp/bl/pl > > #!/usr/bin/perl > > > > use strict; > > use OpenInteract::Startup; > > > > my $HANDLER = 'bltest::Handler::superuser'; > > Is this handler name correct? That is, is there a handler class in your > site in a file called 'superuser.pm'? The handler should be set to a > class in your site which acts as a handler. In your case, the following > should work: > > my $HANDLER = 'bltest::Handler::User'; > > The reason being that if you set $HANDLER to something not in the system > then it's not so instructive when you change the user ID we're fetching > to something that is not the superuser. > > Anyway, the only other thing I can think of is to ensure in the website > you're actually logged in as the superuser. You should be able to see a > line in your error log like: > > OpenInteract::Auth::user (33) >> User found: superuser > > near the top of the entries for a particular request. Make sure you > check the log for the exact request you're having problems with. This > could be an issue where your cookie isn't set properly, is expiring or > is somehow corrupt. I've had the corrupted cookie problem when running > OI on Win2000 with the Apache::Cookie module and either Netscape or IE > (can't remember which). Using CGI::Cookie fixed it right up. > > Chris |
|
From: Bernie L. <Ber...@nt...> - 2002-03-07 09:06:16
|
Chris,
Looking at the log file there seems to be still some mysql in there. Any
ideas:
OpenInteract::Error::System::cannot_create_session (334) >> Cannot create
session -- someone is probably using a defunct key or something.
>> Error with code 310 thrown. Info: DBD::Pg::st execute failed: ERROR:
Function 'get_lock(unknown, int4)' does not exist at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
(in cleanup) DBD::Pg::st execute failed: ERROR: Function
'get_lock(unknown, int4)' does not exist at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
OpenInteract::Error::System::log_and_return('bltest::ErrorObject=HASH(0x8d07080)')
called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/System.pm line 341
OpenInteract::Error::System::cannot_create_session('bltest::ErrorObject=HASH(0x8d07080)')
called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/Main.pm line 38
Bernie.
|
|
From: Chris W. <ch...@cw...> - 2002-03-07 12:40:06
|
On Thu, 2002-03-07 at 04:11, Bernie Ledwick wrote:
> Chris,
>
> Looking at the log file there seems to be still some mysql in there. Any
> ideas:
>
> OpenInteract::Error::System::cannot_create_session (334) >> Cannot create
> session -- someone is probably using a defunct key or something.
> >> Error with code 310 thrown. Info: DBD::Pg::st execute failed: ERROR:
> Function 'get_lock(unknown, int4)' does not exist at
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
> (in cleanup) DBD::Pg::st execute failed: ERROR: Function
> 'get_lock(unknown, int4)' does not exist at
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
>
> OpenInteract::Error::System::log_and_return('bltest::ErrorObject=HASH(0x8d07080)')
> called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/System.pm line 341
>
> OpenInteract::Error::System::cannot_create_session('bltest::ErrorObject=HASH(0x8d07080)')
> called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/Main.pm line 38
Ah! This is in your server configuration. See the 'session_info' key and
change 'class' to 'Apache::Session::Postgres', then restart (stop, then
start) your server.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: Bernie L. <Ber...@nt...> - 2002-03-07 23:17:37
|
Chris, Many thanks for your forebearance. Setting Apache::Session::Postgres makes all the difference - I missed that bit of the documentation. Any chance of this being included in the "change_spops_driver" bit or am I being optimistic? I think I'm going to really enjoy this product. Regards, Bernie. |
|
From: Chris W. <ch...@cw...> - 2002-03-08 03:39:14
|
On Thu, 2002-03-07 at 18:22, Bernie Ledwick wrote: > Many thanks for your forebearance. No problem. I should have picked up on the issue earlier -- it's going in the FAQ right now :-) > Setting Apache::Session::Postgres makes all the difference - I missed that > bit of the documentation. Any chance of this being included in the > "change_spops_driver" bit or am I being optimistic? Optimistic :-) I'm wary of rewriting the server configuration file because it's so large. The SPOPS driver issue shouldn't be so large in the future since I'll probably make it a property of the datasource -- drivers won't have to specify SPOPS::DBI::Pg, MySQL, or whatever. > I think I'm going to really enjoy this product. Excellent! If you have any more questions please post them: you not only never know how they'll end up, you never know how many people you'll help out from the archived version. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X