Menu
▾
▴
binarycloud-dev
|
From: Nico G. <sc...@ac...> - 2001-05-26 21:55:43
|
--* Alex Black (Sat, May 26, 2001 at 01:37:00PM -0700) *--
> > anyway, thanks for your remarks and i'm glad you like the code. btw, =
the
> > way bc encourages the config is with track_vars =3D On; and
> > register_globals =3D Off; right?
>=20
> exactly, though that will quickly kill an r1 installation, the goal for=
r2
> is to filter all input through a request class (which I sort of have, b=
ut
> need to integrate)
hmm, what exactly do you mean with a 'request' class?
--nico
--
nico galoppo - tremelo/leuven, belgium
- erasmus/socrates student in grenoble, france
- 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19
---------------------------------------------------------------
[bash]:~$ man woman nico at crossbar dot net
No manual entry for woman debian linux :: vim powered
|
|
From: Alex B. <en...@tu...> - 2001-05-28 17:59:09
|
ok, I'm a lamer, I finished the Lang class yesterday instead of doing public cvs properly... so, because in the US tooday is a holiday (which means no phone calls!) I will be able to put it up today. - Would it be useful for me to write "task profile" documents for things like the cache component, and sign people up to do things? (i.e. does anyone think that would be useful) - If you would like CVS access, please email me: en...@tu... privately with the username and password you would like. I will respond with a confirmation that your account is active. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: spiggy <th...@me...> - 2001-05-31 02:02:40
|
ok. i got it working on apache/win2k and then did it the same way with linux and it works fine now. the problem was an user error (go figure).. i defined BC_DOCROOT as something else than it was... instead of having nothing in it, i had /bc. after this was solved all i needed to do was to delete some empty spaces in the end of couple of files. paivi |
|
From: Alex B. <ab...@be...> - 2001-05-31 04:14:26
|
excellent! BC_DOCROOT is the only funky thing in bc/r1, anyway no such problems exist (or will) with r2 with installation. Interesting that an incorrect BC_DOCROOT kills your page render though... :) for those of you with CVS problems, I am out of town at the moment, and I'll see if I can get to it tomorrow. I tested this afternoon and it is broken for me too. _a |
|
From: Alex B. <en...@tu...> - 2001-05-26 22:43:54
|
> hmm, what exactly do you mean with a 'request' class?
>
> --nico
binarycloud r1 assumes in a number of places that register_globals is _on_.
for a number of reasons that isn't the best idea, 99% of those reasons are
for security. in binarycloud r2 docs, we will strongly encourage that you
turn register_globals _off_ and for any contributed modules that will be
distributed with binarycloud, we will require (among other things) that you
use $Request->GetVar instead of assuming register_globals is on. Of course,
if that pisses you off, you don't have to use it... just turn
register_globals on and go about your business. (but don't get pissed off
when someone manages to post php code or javascript into your database
because you weren't watching closely :)
so, it's best to get all of your incoming user vars from one place, i.e. a
core class:
$Request->GetVar('foo');
that way, users can't post strange things into your environment without your
knowledge, because you have to explicitly request each variable.
why this and not $HTTP_POST_VARS[foo] ? because it's nice to be able to
build code that will work with a get ?foo=stuff or a post.
we could also build in some very simple checks that look for tags, etc.
---
_alex
--
alex black, ceo
en...@tu...
the turing studio, inc.
http://www.turingstudio.com
vox+510.666.0074
fax+510.666.0093
|
|
From: Michael K. <mi...@ta...> - 2001-05-26 22:59:05
|
<snip>
we will require (among other things) that you
> use $Request->GetVar instead of assuming register_globals is on. Of
course,
> if that pisses you off, you don't have to use it... just turn
> register_globals on and go about your business. (but don't get pissed off
> when someone manages to post php code or javascript into your database
> because you weren't watching closely :)
>
> so, it's best to get all of your incoming user vars from one place, i.e. a
> core class:
>
> $Request->GetVar('foo');
>
> that way, users can't post strange things into your environment without
your
> knowledge, because you have to explicitly request each variable.
>
> why this and not $HTTP_POST_VARS[foo] ? because it's nice to be able to
> build code that will work with a get ?foo=stuff or a post.
Ideally, you'd still keep both - so you could POST to
foo.com/something/param1/param2
and get the params as GET and your POSTed stuff as POST.
But that's not why I write...
We've put together something similar to bc, and had to make the same
decision
awhile ago, and it's something we enforce - no option to turn globals on -
actually, I don't care if they're on, no code references anything by
globals.
This was fine for the core of us using it, and caused consternation when
someone
new came on board who wasn't use to it. And I remember hating it in ASP a
few years
ago.
foo.com/index.php?bar=cow
having $bar=="cow" *automatically* was one of the big selling points of PHP
back then.
But as we've noticed throughout the years, and Alex points out again,
security
is a concern with this. And forcing this kind of structure on to an
application
can only help as it gets bigger. Also, another neat thing we've been able
to do
easily (not that it couldn't be done with HTTP_POST_VARS, etc) is log
request data.
In one app, we log all incoming POST data - it helped for debugging, and we
just left it
in. It helps occasionally troubleshoot problems we have with user errors
("I didn't
make that purchase!" - well, the POST data from your IP at that time shows
you did, etc.)
Overkill for most apps, yes, but imposing these kinds of structures can
really be
helpful. Wow, maybe ASP had a redeeming quality? ;)
MK
|
|
From: Alex B. <en...@tu...> - 2001-05-26 23:43:57
|
> Wow, maybe ASP had a redeeming quality? ;) ugh, I suppose so. :) _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Michael K. <mi...@ta...> - 2001-05-26 23:53:30
|
> > Wow, maybe ASP had a redeeming quality? ;)
>
> ugh, I suppose so. :)
>
> _a
>
Well, kinda, yeah. But it didn't have anything as cool as extract, AFAIR.
We put args into a system object, which gets passed around to the various
classes.
function blah($x,$y,$obj) {
extract($obj->postvars);
extract($obj->getvars);
}
Rather the best of both world, imo. Structure plus extract(). :)
MK
|
|
From: Michael K. <mi...@ta...> - 2001-05-26 23:54:04
|
> > Wow, maybe ASP had a redeeming quality? ;)
>
> ugh, I suppose so. :)
>
> _a
>
Well, kinda, yeah. But it didn't have anything as cool as extract, AFAIR.
We put args into a system object, which gets passed around to the various
classes.
function blah($x,$y,$obj) {
extract($obj->postvars);
extract($obj->getvars);
}
Rather the best of both world, imo. Structure plus extract(). :)
MK
|
|
From: Michael K. <mi...@ta...> - 2001-05-26 22:59:08
|
<snip>
we will require (among other things) that you
> use $Request->GetVar instead of assuming register_globals is on. Of
course,
> if that pisses you off, you don't have to use it... just turn
> register_globals on and go about your business. (but don't get pissed off
> when someone manages to post php code or javascript into your database
> because you weren't watching closely :)
>
> so, it's best to get all of your incoming user vars from one place, i.e. a
> core class:
>
> $Request->GetVar('foo');
>
> that way, users can't post strange things into your environment without
your
> knowledge, because you have to explicitly request each variable.
>
> why this and not $HTTP_POST_VARS[foo] ? because it's nice to be able to
> build code that will work with a get ?foo=stuff or a post.
Ideally, you'd still keep both - so you could POST to
foo.com/something/param1/param2
and get the params as GET and your POSTed stuff as POST.
But that's not why I write...
We've put together something similar to bc, and had to make the same
decision
awhile ago, and it's something we enforce - no option to turn globals on -
actually, I don't care if they're on, no code references anything by
globals.
This was fine for the core of us using it, and caused consternation when
someone
new came on board who wasn't use to it. And I remember hating it in ASP a
few years
ago.
foo.com/index.php?bar=cow
having $bar=="cow" *automatically* was one of the big selling points of PHP
back then.
But as we've noticed throughout the years, and Alex points out again,
security
is a concern with this. And forcing this kind of structure on to an
application
can only help as it gets bigger. Also, another neat thing we've been able
to do
easily (not that it couldn't be done with HTTP_POST_VARS, etc) is log
request data.
In one app, we log all incoming POST data - it helped for debugging, and we
just left it
in. It helps occasionally troubleshoot problems we have with user errors
("I didn't
make that purchase!" - well, the POST data from your IP at that time shows
you did, etc.)
Overkill for most apps, yes, but imposing these kinds of structures can
really be
helpful. Wow, maybe ASP had a redeeming quality? ;)
MK
|
|
From: Alex B. <en...@tu...> - 2001-05-26 23:47:51
|
btw: everyone thank Nico, because of his _excellent_ code, I am very very nearly done with the Lang class. (on that note, has anyone had trouble with session_is_registered always returning true? agh!) > Ideally, you'd still keep both - so you could POST to > foo.com/something/param1/param2 > > and get the params as GET and your POSTed stuff as POST. correct. > But that's not why I write... > > We've put together something similar to bc, and had to make the same decision > awhile ago, and it's something we enforce - no option to turn globals on - > actually, I don't care if they're on, no code references anything by globals. > This was fine for the core of us using it, and caused consternation when > someone new came on board who wasn't use to it. And I remember hating it in > ASP a few years ago. Right, which is why I will _only_ require people that want to _distribute_ modules with binarycloud to use Request. But I will encourage the hell out of turning off register_globals. If the idea of using $Request->GetVar('foo'); is foreign, you can keep register_globals = on and not have a problem. I will likely have it on in the distro php.ini so people aren't confused when they do an install. But, for security, it's pretty bad to keep it on :) > foo.com/index.php?bar=cow > > having $bar=="cow" *automatically* was one of the big selling points of PHP > back then. But as we've noticed throughout the years, and Alex points out > again, security is a concern with this. And forcing this kind of structure on > to an application can only help as it gets bigger. Also, another neat thing > we've been able to do easily (not that it couldn't be done with > HTTP_POST_VARS, etc) is log request data. In one app, we log all incoming POST > data - it helped for debugging, and we just left it in. It helps occasionally > troubleshoot problems we have with user errors ("I didn't make that purchase!" > - well, the POST data from your IP at that time shows you did, etc.) Overkill > for most apps, yes, but imposing these kinds of structures can really be > helpful. Wow, maybe ASP had a redeeming quality? ;) yes, exactly. you can easily extend request to keep an _autitable_trail_ of _every_single_thing_ever_ that comes into the app :) now, for joe bob's beer mart, this is probably not a big concern, for some other people I know... yeah.. bigtime. -alex |
|
From: Michael K. <mi...@ta...> - 2001-05-27 00:04:45
|
<snip>
It helps occasionally
> > troubleshoot problems we have with user errors ("I didn't make that
purchase!"
> > - well, the POST data from your IP at that time shows you did, etc.)
Overkill
> > for most apps, yes, but imposing these kinds of structures can really be
> > helpful. Wow, maybe ASP had a redeeming quality? ;)
>
> yes, exactly. you can easily extend request to keep an _autitable_trail_
of
> _every_single_thing_ever_ that comes into the app :)
>
> now, for joe bob's beer mart, this is probably not a big concern, for some
> other people I know... yeah.. bigtime.
>
I think I'm posting twice - sorry. Using outlook, and I just ain't used to
it! :(
On another note - back in the day, we had a company come in to my office
that was going to sell us log analysis software. They also had a hardware
sniffer that would sniff and log ALL data to an SQL database (probably
only MS at the time). Their big claim to fame at the time was that it
logged
POST data as well as GET stuff, and it'd sort it out into columns in a
table,
so you could query against it later. Breaking each GET/POST variable
into a column might be overkill, but the idea had appeal. MINIMUM $25k,
which sounded a lot at the time. It scaled per website on your network,
which seemed a poor way of doing it - we had some sites with 50+ servers,
and some shared on 1 server.
Anyway, the crux is that having this capability in an app system is
quite useful. We've got it in place, and as I said, for some sites,
one in particular, it's great. Yeah, it can slow the servers down some a
bit,
but when you've got multiple servers in the first place, it ain't too bad.
And certainly cheaper than a hardware sniffer. :)
I certainly don't recall being able to do this in ASP, although I'm sure you
*could*.
Certainly wouldn't be as easy, imo, as PHP.
Anyway, just saying good luck with the project. :)
MK
|
|
From: Alex B. <en...@tu...> - 2001-05-27 00:25:51
|
> On another note - back in the day, we had a company come in to my office > that was going to sell us log analysis software. They also had a hardware > sniffer that would sniff and log ALL data to an SQL database (probably > only MS at the time). Their big claim to fame at the time was that it > logged > POST data as well as GET stuff, and it'd sort it out into columns in a > table, heheh. anyone want to volunteer to build a get/post logger into Request after it's finished? that _would_ be pretty cool... well, there's also the caching component to build, but (hopefully) that will be fairly easy as there is a fair amount of code out there. _alex > so you could query against it later. Breaking each GET/POST variable > into a column might be overkill, but the idea had appeal. MINIMUM $25k, > which sounded a lot at the time. It scaled per website on your network, > which seemed a poor way of doing it - we had some sites with 50+ servers, > and some shared on 1 server. -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Nico G. <sc...@ac...> - 2001-05-27 08:21:39
|
--* Alex Black (Sat, May 26, 2001 at 05:26:09PM -0700) *--
> well, there's also the caching component to build, but (hopefully) that=
will
> be fairly easy as there is a fair amount of code out there.
could you run by me again why PEAR::Cache isn't good enough? I think you
said something about garbage collecting. what exactly is that, and are
you sure it isn't in PEAR::Cache already?
--nico
--
nico galoppo - tremelo/leuven, belgium
- erasmus/socrates student in grenoble, france
- 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19
---------------------------------------------------------------
[bash]:~$ man woman nico at crossbar dot net
No manual entry for woman debian linux :: vim powered
|
|
From: alex b. <en...@tu...> - 2001-05-27 18:44:58
|
we may use PEAR_Cache, though we will need to either wrap it, or extend it. It doesn't have any of the "directory maintenance" stuff we need. After Lang and Auth/Perm are up, I'm going to examine PEAR_Cache once n' for all, and see if we can use it. _a ----- Original Message ----- From: "Nico Galoppo" <sc...@ac...> To: <bin...@li...> Sent: Sunday, May 27, 2001 1:21 AM Subject: [binarycloud-dev] Cache [was: Re: Lang ] > --* Alex Black (Sat, May 26, 2001 at 05:26:09PM -0700) *-- > > > well, there's also the caching component to build, but (hopefully) that will > > be fairly easy as there is a fair amount of code out there. > > could you run by me again why PEAR::Cache isn't good enough? I think you > said something about garbage collecting. what exactly is that, and are > you sure it isn't in PEAR::Cache already? > > --nico > > -- > nico galoppo - tremelo/leuven, belgium > - erasmus/socrates student in grenoble, france > - 4, rue béranger -- phone: +33-(0)76-85 23 19 > --------------------------------------------------------------- > [bash]:~$ man woman nico at crossbar dot net > No manual entry for woman debian linux :: vim powered > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
×
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