gubed-devel

[gbd-dev] Global and local settings

[Linus M. <Li...@mc...>]

Hello

Here's an attempt to summarize the discussions on security, global and user 
settings, and temporary overriding of settings:

1) New setting items are added, 
  * allow remote clients
  * enable developer help
  * allow user override on http request
  * allow settingsfile override on http request
  * allow host and port override on http request (or do we need separate 
settings for these?)

These items will reside in a file 'globalsettings.php' which will work similar 
to how localsettings does today. 
This file will have the required comments to make sure the user understand 
what s/he enabling.

2) After this file is read, Gubed will optionally look for a user settings 
file but this file is not a php file but a config file (parse_ini_file helps 
here) so that only allowed settings can be changed.

To find the correct user config file, Gubed will search in the following 
locations and take the first one it finds:
  * file specified on http request - if this is allowed in global settings
  * localsettings_{$user}.ini where $user is specified on http request and 
user overriding is enabled in global settings.
  * localsettings_{$user}.ini where $user is $_SERVER["REMOTE_USER"].
  * localsettings.ini - is this really needed?

3) After the user settings is read, optionally host and port may be changed by 
the http request if this is allowed by the global settings.

4) The developer helper scripts are updated to only work if they are enabled.

5) We will have to remember that this must all work also when not using 
StartSession

Did I forget anything?

/Linus

[gbd-dev] Pass Parameters to Target Scripts

[Brett S. <tec...@se...>]

I need to debug scripts that have parameters.

For instance, 'target.php?a=myvalue'

StartSession.php ends up running like:

StartSession.php?gbdScript=target.php

Syntax such as:

StartSession.php?gbdScript=target.php?a=myvalue

would not be legal and doesn't seem to work.

How is this done?

Brett

-------------------------------------
Brett C. Serkez, Technical Trainer

[gbd-dev] Re: Pass Parameters to Target Scripts

[Brett S. <tec...@se...>]

Found atleast a working answer, could be more robust later.

> I need to debug scripts that have parameters.
>
> For instance, 'target.php?a=myvalue'
>
> StartSession.php ends up running like:
>
> StartSession.php?gbdScript=target.php

Once control transfers to the Gubed debugger, in the bottom most entry
area type the following:

$_GET['a']='myvalue'

where 'a' is the name of the variable and 'myvalue' is its value.

Then click on 'Process'.

Brett
-------------------------------------
Brett C. Serkez, Technical Trainer

Re: [gbd-dev] Re: Pass Parameters to Target Scripts

[Linus M. <Li...@mc...>]

True, this is another way of doing it

/Linus


On Monday 27 June 2005 03.39, Brett Serkez wrote:
> Found atleast a working answer, could be more robust later.
>
> > I need to debug scripts that have parameters.
> >
> > For instance, 'target.php?a=myvalue'
> >
> > StartSession.php ends up running like:
> >
> > StartSession.php?gbdScript=target.php
>
> Once control transfers to the Gubed debugger, in the bottom most entry
> area type the following:
>
> $_GET['a']='myvalue'
>
> where 'a' is the name of the variable and 'myvalue' is its value.
>
> Then click on 'Process'.
>
> Brett
> -------------------------------------
> Brett C. Serkez, Technical Trainer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gubed-devel mailing list
> Gub...@li...
> https://lists.sourceforge.net/lists/listinfo/gubed-devel

Re: [gbd-dev] Pass Parameters to Target Scripts

[Linus M. <Li...@mc...>]

You should only have to exchange the second ? with a & and it should work. 
This should happen automatically when the output is processed by Gubed, but if 
you create the StartSession line yourself, youll have to do it manually...

/Linus

On Sunday 26 June 2005 22.15, Brett Serkez wrote:
> I need to debug scripts that have parameters.
>
> For instance, 'target.php?a=myvalue'
>
> StartSession.php ends up running like:
>
> StartSession.php?gbdScript=target.php
>
> Syntax such as:
>
> StartSession.php?gbdScript=target.php?a=myvalue
>
> would not be legal and doesn't seem to work.
>
> How is this done?
>
> Brett
>
> -------------------------------------
> Brett C. Serkez, Technical Trainer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gubed-devel mailing list
> Gub...@li...
> https://lists.sourceforge.net/lists/listinfo/gubed-devel

RE: [gbd-dev] Global and local settings

[Aaron M. <wmc...@ho...>]

I think you covered everything and I think that the host and port override 
options should be separate. But will the user's localsettings file need to 
reside in the ServerScripts directory or could it exist elsewhere? Here are 
a couple of ideas.

>* localsettings_{$user}.ini where $user is specified on http request and
user overriding is enabled in global settings.

I'm thinking that the regular user wouldn't typically have permission to 
write to the ServerScripts directory which might be owned by a more 
privileged user, for example,  on a Linux server. I propose a 
/home/user/.gubed directory in which a user would place localsettings.ini.

>* localsettings_{$user}.ini where $user is $_SERVER["REMOTE_USER"].

The HTTP authenticated user may not have an account on the server and so the 
sysadmin would likely have to create the localsettings file for the user in 
say a subdirectory of ServerScripts.

The search would then be:
  * file specified on http request - if this is allowed in global settings
  * /home/$user/.gubed/localsettings.ini where $user is specified on http 
request and
user overriding is enabled in global settings.
  * ServerScripts/localsettings/localsettings_{$user}.ini where $user is 
$_SERVER["REMOTE_USER"].


Thanks,
Aaron McDonald

------------------------------------------------------------------------------------------------------------------------

Hello

Here's an attempt to summarize the discussions on security, global and user
settings, and temporary overriding of settings:

1) New setting items are added,
  * allow remote clients
  * enable developer help
  * allow user override on http request
  * allow settingsfile override on http request
  * allow host and port override on http request (or do we need separate
settings for these?)

These items will reside in a file 'globalsettings.php' which will work 
similar
to how localsettings does today.
This file will have the required comments to make sure the user understand
what s/he enabling.

2) After this file is read, Gubed will optionally look for a user settings
file but this file is not a php file but a config file (parse_ini_file helps
here) so that only allowed settings can be changed.

To find the correct user config file, Gubed will search in the following
locations and take the first one it finds:
  * file specified on http request - if this is allowed in global settings
  * localsettings_{$user}.ini where $user is specified on http request and
user overriding is enabled in global settings.
  * localsettings_{$user}.ini where $user is $_SERVER["REMOTE_USER"].
  * localsettings.ini - is this really needed?

3) After the user settings is read, optionally host and port may be changed 
by
the http request if this is allowed by the global settings.

4) The developer helper scripts are updated to only work if they are 
enabled.

5) We will have to remember that this must all work also when not using
StartSession

Did I forget anything?

/Linus

Re: [gbd-dev] Global and local settings

[Linus M. <Li...@mc...>]

On Monday 27 June 2005 02.40, Aaron McDonald wrote:
> I'm thinking that the regular user wouldn't typically have permission to
> write to the ServerScripts directory which might be owned by a more
> privileged user, for example,  on a Linux server. I propose a
> /home/user/.gubed directory in which a user would place localsettings.ini.

Good idea. Do you have any idea how is this done on windows? :]

> The search would then be:
>   * file specified on http request - if this is allowed in global settings
>   * /home/$user/.gubed/localsettings.ini where $user is specified on http
> request and
> user overriding is enabled in global settings.
>   * ServerScripts/localsettings/localsettings_{$user}.ini where $user is
> $_SERVER["REMOTE_USER"].

I think it should look  in the same place wether the username is specified by 
the request or REMOTE_USER.

/Linus

Re: [gbd-dev] Global and local settings

[Brett S. <tec...@se...>]

> > I'm thinking that the regular user wouldn't typically have permission to
> > write to the ServerScripts directory which might be owned by a more
> > privileged user, for example,  on a Linux server. I propose a
> > /home/user/.gubed directory in which a user would place localsettings.ini.
> 
> Good idea. Do you have any idea how is this done on windows? :]

The 'comparable' location on windows:

C:\Documents and Settings\user\...

Unless we want to use the registry.  :-o

Brett

-------------------------------------
Brett C. Serkez, Technical Trainer

Re: [gbd-dev] Global and local settings

[Linus M. <Li...@mc...>]

On Monday 27 June 2005 12.13, Brett Serkez wrote:
> > > I'm thinking that the regular user wouldn't typically have permission
> > > to write to the ServerScripts directory which might be owned by a more
> > > privileged user, for example,  on a Linux server. I propose a
> > > /home/user/.gubed directory in which a user would place
> The 'comparable' location on windows:
>
> C:\Documents and Settings\user\...

I just wish there had been a more php-ish way to do it. 

If we go with Aarons suggestion and have a subdirectory for the user settings, 
we could have that as a default with commented suggestions for windows and 
linux:

$gbdUserhome =  './Users/';
//$gbdUserhome =  'c:\\Documents and Settings\\';
//$gbdUserhome =  '/home/';

If you want a multiuser setup you will need to do a little more tweaking of 
settings anyway, so I'd think it's acceptable?

/linus

Re: [gbd-dev] Global and local settings

[Brett S. <tec...@se...>]

> > > > I'm thinking that the regular user wouldn't typically have permission
> > > > to write to the ServerScripts directory which might be owned by a more
> > > > privileged user, for example,  on a Linux server. I propose a
> > > > /home/user/.gubed directory in which a user would place
> > The 'comparable' location on windows:
> >
> > C:\Documents and Settings\user\...
> 
> I just wish there had been a more php-ish way to do it. 
> 
> If we go with Aarons suggestion and have a subdirectory for the user
> settings, 
> we could have that as a default with commented suggestions for windows
> and 
> linux:
> 
> $gbdUserhome =  './Users/';
> //$gbdUserhome =  'c:\\Documents and Settings\\';
> //$gbdUserhome =  '/home/';
> 
> If you want a multiuser setup you will need to do a little more tweaking
> of 
> settings anyway, so I'd think it's acceptable?

Yes.

Brett
-------------------------------------
Brett C. Serkez, Technical Trainer