Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: alex b. <en...@tu...> - 2001-05-29 03:17:04
|
> $Request->GetVar('foo', 'POST');
I think we will have that, and likely use the "default order" from the order
set in ini.
I am considering adding "intelligence" to the class, which would optionally
filter incoming variables and warn if there are basic things like php tags,
etc.
> Just an idea, I don't have a good enough understanding of the
> Binarycloud system yet to know whether or not that idea would fit in
> with the rest.
No, that is a good idea, and exactly how I will implement it :)
> p.s. I also think the decision to go with XSLT as the default
> template class is a Good Idea ;)
danke :)
there's _much_ more coming re: that, btw.
_alex
|
|
From: David W. <dwe...@po...> - 2001-05-28 22:22:55
|
I wanted to chime in and applaud the decision to *not* rely on
register_globals with Binarycloud r2. I never liked how PHP litters
the global namespace with anything that a user may submit.
I also have a feature request for the Request class. I think it would
nice if you could restrict which class of variable you want to
retrieve, for example, you might want to restrict a form to POST
only. In that situation, you could do:
$Request->GetVar('foo', 'POST');
Just an idea, I don't have a good enough understanding of the
Binarycloud system yet to know whether or not that idea would fit in
with the rest.
-dave
p.s. I also think the decision to go with XSLT as the default
template class is a Good Idea ;)
--
David Weingart
dwe...@po...
The foot can split wood, but it can't split a watermelon.
|
|
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: 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 > |
|
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 06:13:49
|
> compatitively agh! comparatively! _a |
|
From: alex b. <en...@tu...> - 2001-05-27 06:03:58
|
woohoo!
lang is working, I am able to set language based on:
-session. if not session,
-HTTP_ACCEPT_LANGUAGE (assuming this can be found in the langs =
array, defined in user/conf/langs.php, from user/conf/langs.xml)
-defualt language defined in the langs array.
tomorrow, I will complete the class so it sets currency, date_time, =
etc... this is compatitively quite simple because all that information =
is in the lang definition array.
note that we will have xml->php makefile abilities very soon, this is =
when the development will pick up much speed, and things will start =
coming out very fast.
Nico's cotribution has spurned me into getting a fully synched, =
accessible cvs going on binarycloud.com - I will attempt to set this up =
tomorrow. If anyone wants a login, let me know.
_alex
|
|
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: 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: 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 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: 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: 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 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: 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 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: 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-26 20:41:50
|
> function _set_system_constatns() in init.php, it use the value of > $HTTP_SERVER_VARS["DOCUMENT_ROOT"] to define BC_PATH_HTDOCS, but if > something use PWS or IIS, the result will different from Apache, better try > to identify the web server and use different environment variable. For PWS > and IIS, pls try $HTTP_SERVER_VARS[APPL_PHYSICAL_PATH]. If you have no time > and testing machine, I am happy to work on it in next shell release. hm, I have considered having this be a user configuration constant, that people are responsible for setting in user/conf/conf.xml --- I think I'll do that instead of putting in more logic. _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-05-26 20:41:49
|
>> Ah, so you are running a virtualhost, cool. >> Do you have any special directives in the vhost? >> what about a .htaccess in a higher-level directory? > > i havent created a single .htaccess file anywhere. httpd.conf is basic > except for the virtualhosts. are there any apache modules that should be > avoided? or that prevent bc from working correctly? > >> are you using your own php.ini or the binarycluod distro php.ini? > > i had my own but i tried the distro version too. i had to change mm to files > (session_save_path). but this should not make any difference as far as i can > see. > > all the directives in the virtualhost definitions do not have to be > duplicated in php.ini.. right? > > still a blank page. ag! you're doing everything right :) hmm... double check: php_value allow_call_time_pass_by_reference 1 use the distro php.ini (with your modification mm->files) comment out session_start() in /path/to/htdocs/index.php ... _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: TAO R. <ron...@ho...> - 2001-05-26 12:51:33
|
hi alex, function _set_system_constatns() in init.php, it use the value of $HTTP_SERVER_VARS["DOCUMENT_ROOT"] to define BC_PATH_HTDOCS, but if something use PWS or IIS, the result will different from Apache, better try to identify the web server and use different environment variable. For PWS and IIS, pls try $HTTP_SERVER_VARS[APPL_PHYSICAL_PATH]. If you have no time and testing machine, I am happy to work on it in next shell release. Ronald TAO ron...@ho... _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
|
From: Spiggy T. <th...@me...> - 2001-05-26 02:33:59
|
> Ah, so you are running a virtualhost, cool. > Do you have any special directives in the vhost? > what about a .htaccess in a higher-level directory? i havent created a single .htaccess file anywhere. httpd.conf is basic except for the virtualhosts. are there any apache modules that should be avoided? or that prevent bc from working correctly? > are you using your own php.ini or the binarycluod distro php.ini? i had my own but i tried the distro version too. i had to change mm to files (session_save_path). but this should not make any difference as far as i can see. all the directives in the virtualhost definitions do not have to be duplicated in php.ini.. right? still a blank page. |
|
From: alex b. <en...@tu...> - 2001-05-26 02:11:53
|
> 'htdocs' for bc is located at /web/bc/, binarycloud is at > /include/binarycloud/. i get what i get when i go to http://binarycloud/, > same when i add index.php, no loops as far as i can see... thats pretty much > all i can think about. Ah, so you are running a virtualhost, cool. Do you have any special directives in the vhost? what about a .htaccess in a higher-level directory? are you using your own php.ini or the binarycluod distro php.ini? > virtualhost is straight from your site (with paths changed), except that i > use the local ip address for the virtualhost. apache is running as > nobody.nobody and the files are owned by the server. hmm, that sounds right... _a |
|
From: Spiggy T. <th...@me...> - 2001-05-26 02:00:20
|
'htdocs' for bc is located at /web/bc/, binarycloud is at /include/binarycloud/. i get what i get when i go to http://binarycloud/, same when i add index.php, no loops as far as i can see... thats pretty much all i can think about. virtualhost is straight from your site (with paths changed), except that i use the local ip address for the virtualhost. apache is running as nobody.nobody and the files are owned by the server. ----- Original Message ----- From: "Alex Black" <en...@tu...> To: "binarycloud-dev" <bin...@li...> Sent: Friday, May 25, 2001 9:05 PM Subject: Re: [binarycloud-dev] blank page with binarycloud r1 > >> what does the url look like in your browser? > >> try editing binarycloud/user/conf/prepend.inc > >> > >> find this line: > >> check_permissions($perms_group); > > > > woohoo! i have something: the banner image, menu (no links) and > > > > Fatal error: Call to undefined function: get_directory_names_array() in > > /include/binarycloud/core/lib/bread_crumbs_and_tabs.lib on line 78 > > > > err.. alex, im assuming you know what this means :)? > > yes. that function: > get_directory_names_array() > is contained in the file whose line you commented out :) > > --- > > but the important question is, what are you getting the blank page? > so: > -do you have binarycloud somewhere strange (like /docroot/foo/index.php) > in your tree? > -have you noticed that you are actually getting an infinite loop, and > your url is something like: > http://example/place/index.php?rd=/index.php&rd=index.php etc? > > give me as much info as you can. > > _a > > > > > > -- > alex black, ceo > en...@tu... > > the turing studio, inc. > http://www.turingstudio.com > > vox+510.666.0074 > fax+510.666.0093 > > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > |
|
From: Alex B. <en...@tu...> - 2001-05-26 01:05:43
|
>> what does the url look like in your browser?
>> try editing binarycloud/user/conf/prepend.inc
>>
>> find this line:
>> check_permissions($perms_group);
>
> woohoo! i have something: the banner image, menu (no links) and
>
> Fatal error: Call to undefined function: get_directory_names_array() in
> /include/binarycloud/core/lib/bread_crumbs_and_tabs.lib on line 78
>
> err.. alex, im assuming you know what this means :)?
yes. that function:
get_directory_names_array()
is contained in the file whose line you commented out :)
---
but the important question is, what are you getting the blank page?
so:
-do you have binarycloud somewhere strange (like /docroot/foo/index.php)
in your tree?
-have you noticed that you are actually getting an infinite loop, and
your url is something like:
http://example/place/index.php?rd=/index.php&rd=index.php etc?
give me as much info as you can.
_a
--
alex black, ceo
en...@tu...
the turing studio, inc.
http://www.turingstudio.com
vox+510.666.0074
fax+510.666.0093
|
|
From: Spiggy T. <th...@me...> - 2001-05-26 00:51:27
|
> what does the url look like in your browser? > try editing binarycloud/user/conf/prepend.inc > > find this line: > check_permissions($perms_group); woohoo! i have something: the banner image, menu (no links) and Fatal error: Call to undefined function: get_directory_names_array() in /include/binarycloud/core/lib/bread_crumbs_and_tabs.lib on line 78 err.. alex, im assuming you know what this means :)? |
5 messages has been excluded from this view by a project administrator.
