headers
Manuel Holtgrewe | 1 Aug 2004 14:16

Re: Init change and complains


Am 31.07.2004 um 18:12 schrieb Jason Hines:

> What did we agree on for retreiving the Init instance?
>
> 1. Override getInstance()
> 2. Make Init completely static
> 3. Other?

I'd like to propose that Init could be renamed to Project to reflect 
that it is inherited for each project when you need non default 
behaviour (you should be able to work with good defaults of stock 
Project, though). The base class Project should have a configureable 
"getInstance()" method.

In conf/Common.conf.xml:

<section name="common">
   <param name="project_class">path/to/custom/Project.php</param>
</section>

in binarycloud/init/Project.php:

function &getInstance() {
   static $instance = null;

   if ($instance == null) {
     $conf =& Conf::getInstance('conf/Common.php');
     $settings = $conf->getConf('common');
(Continue reading)

Permalink | Reply | 9 comments |
headers
Manuel Holtgrewe | 1 Aug 2004 14:17

Re: lesser package coupling in binarycloud


Am 31.07.2004 um 21:41 schrieb Jason Hines:

>
>
> Jean-Christophe Michel wrote:
>>> The real difference here is that classes like Session.php and 
>>> Log.php need to act as managers for their drivers.  In my opinion, 
>>> Init should be the place to feed this info into the manager.
>> The code could be the same, but Log::getInstance() would read the 
>> conf and instanciate the right driver, all extending Log. Same for 
>> Sessions.
>> So would Init call the right method.
>
> So you're saying Log::getInstance() should read conf, and configure 
> itself - as opposed to having Init configure it.  (same for session 
> too)
> This way, Init would not need to do anything at all.  The 
> getInstance() method for each class would also configure the 
> appropriate driver/handler.

Seems good: Even more decoupling from Init.
Permalink | Reply | 2 comments |
headers
Manuel Holtgrewe | 1 Aug 2004 14:24

Debugging/Logging

Hi

I think we should polish up Debugging and Logging a bit more. The whole 
debugging and logging system is consistent, but I'd like to have a bit 
more control about where logging happens etc.

For example, I can enable debug output globally and for certain IP 
(range). However, I'd like to be able to enable it if a certain post 
variable is set because I do not have a static IP on the internet and 
liked to see debug on a beta page, though everybody else should not...

Additionally, I do not know how well file logging etc. work and I think 
something in the Wiki about this would be good, too. What about this 
"wrapped up" log file thing Alex proposed some time ago?

Regard,

Manuel
Permalink | Reply | 11 comments |
headers
Jean-Christophe Michel | 1 Aug 2004 14:28
Favicon

Re: Debugging/Logging

Manuel Holtgrewe wrote:
> Hi
> 
> I think we should polish up Debugging and Logging a bit more. The whole 
> debugging and logging system is consistent, but I'd like to have a bit 
> more control about where logging happens etc.
> 
> For example, I can enable debug output globally and for certain IP 
> (range). However, I'd like to be able to enable it if a certain post 
> variable is set because I do not have a static IP on the internet and 
> liked to see debug on a beta page, though everybody else should not...

A secret cookie would make it easier than a posted param, isn't it ?

I'd like to be able to disable Debug for another build. Is it posisble 
to have a conf for each build.property target ?

--

-- 
Jean-Christophe Michel
Permalink | Reply | 0 comments |
headers
Jason Hines | 1 Aug 2004 16:43

Re: Init change and complains

i like this.

Manuel Holtgrewe wrote:

> 
> Am 31.07.2004 um 18:12 schrieb Jason Hines:
> 
>> What did we agree on for retreiving the Init instance?
>>
>> 1. Override getInstance()
>> 2. Make Init completely static
>> 3. Other?
> 
> 
> I'd like to propose that Init could be renamed to Project to reflect 
> that it is inherited for each project when you need non default 
> behaviour (you should be able to work with good defaults of stock 
> Project, though). The base class Project should have a configureable 
> "getInstance()" method.
> 
> In conf/Common.conf.xml:
> 
> <section name="common">
>   <param name="project_class">path/to/custom/Project.php</param>
> </section>
> 
> in binarycloud/init/Project.php:
> 
> function &getInstance() {
>   static $instance = null;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Hines | 1 Aug 2004 16:51

Re: lesser package coupling in binarycloud


Ok good.  I'm glad my point was understood, though it seems I was 
suggesting the opposite... to make Init the center place for all class 
initialization / configuration.

This would lead to having all objects available with:

$init->session
$init->log
etc.

This would be more (not less) coupling, and would be a change to the 
getInstance() method of object retrieval.

..
So I agree.  Session.php and Log.php should handle their own 
configuration, and Init should not do it for them.

jason

Manuel Holtgrewe wrote:

> 
> Am 31.07.2004 um 21:41 schrieb Jason Hines:
> 
>>
>>
>> Jean-Christophe Michel wrote:
>>
>>>> The real difference here is that classes like Session.php and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Hines | 1 Aug 2004 16:57

Re: Debugging/Logging


Manuel Holtgrewe wrote:
> For example, I can enable debug output globally and for certain IP 
> (range). However, I'd like to be able to enable it if a certain post 
> variable is set because I do not have a static IP on the internet and 
> liked to see debug on a beta page, though everybody else should not...

Security risk!

I would suggest setting allowed_hosts to the CLASS A of your IP.  How 
dynamic is your IP?  Most ISP do not have more than 1 CLASS A.

Eg:
205.*

Earthlink for example, being a huge ISP, only have like 4 or so CLASS 
A's, so you could have them all listed in allowed_hosts.
Permalink | Reply | 9 comments |
headers
Manuel Holtgrewe | 1 Aug 2004 17:25

Re: Debugging/Logging


Am 01.08.2004 um 16:57 schrieb Jason Hines:

>
>
> Manuel Holtgrewe wrote:
>> For example, I can enable debug output globally and for certain IP 
>> (range). However, I'd like to be able to enable it if a certain post 
>> variable is set because I do not have a static IP on the internet and 
>> liked to see debug on a beta page, though everybody else should 
>> not...
>
> Security risk!
>
> I would suggest setting allowed_hosts to the CLASS A of your IP.  How 
> dynamic is your IP?  Most ISP do not have more than 1 CLASS A.
>
> Eg:
> 205.*
>
> Earthlink for example, being a huge ISP, only have like 4 or so CLASS 
> A's, so you could have them all listed in allowed_hosts.

Uhm, even a bigger security risk? You could combine this two things 
anyway... And it is a beta site and having a "BCDEBUG" variable set to 
a certain value (i.e. key) is not that insecure.

Having a client certificate and use SSL/TLS etc. would be really 
secure, but for debugging betas, this is okay IMO.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jason Hines | 1 Aug 2004 17:48

Re: Debugging/Logging


Manuel Holtgrewe wrote:
>>> For example, I can enable debug output globally and for certain IP 
>>> (range). However, I'd like to be able to enable it if a certain post 
>>> variable is set because I do not have a static IP on the internet and 
>>> liked to see debug on a beta page, though everybody else should not...
>>
>>
>> Security risk!
>>
>> I would suggest setting allowed_hosts to the CLASS A of your IP.  How 
>> dynamic is your IP?  Most ISP do not have more than 1 CLASS A.
>>
>> Eg:
>> 205.*
>>
>> Earthlink for example, being a huge ISP, only have like 4 or so CLASS 
>> A's, so you could have them all listed in allowed_hosts.
> 
> Uhm, even a bigger security risk? You could combine this two things 
> anyway... And it is a beta site and having a "BCDEBUG" variable set to a 
> certain value (i.e. key) is not that insecure.

What would be the value of BCDEBUG?  My purpose of allowed_hosts was to 
enfore security, so that only the designated IP range could view 
debugging.  Aside from logging in as a developer, what is a better way 
to identify the browser as being the developer?

This IS an important discussion, seeing as how view Conf debug shows the 
database login information right there on the website.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Daniel Bondurant | 1 Aug 2004 18:08

Re: lesser package coupling in binarycloud

The code could be the same, but Log::getInstance() would read the conf 
> and instanciate the right driver, all extending Log. Same for Sessions.
> So would Init call the right method.

Should Perm be set up the same way?  Perm needs to call the correct
driver (once they are set up).

--

-- 
thanks
- daniel
Permalink | Reply | 0 comments |

Gmane