|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general Digest 9 Jul 2005 07:15:32 -0000 Issue 3557
php-general-digest-help
lists.php.net
Date: Sat Jul 09 2005 - 02:15:32 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 9 Jul 2005 07:15:32 -0000 Issue 3557
Topics (messages 218355 through 218376):
Re: iPowerWeb ISP Are they good?
218355 by: Jason Manaigre
Re: Security, Late Nights and Overall Paranoia
218356 by: Greg Donald
218357 by: Ryan A
218358 by: Edward Vermillion
218359 by: Greg Donald
218360 by: Ezra Nugroho
218361 by: Edward Vermillion
218362 by: Edward Vermillion
218364 by: Ezra Nugroho
218365 by: Edward Vermillion
218366 by: Ezra Nugroho
218367 by: Rory Browne
Re: using require
218363 by: Jeffrey D. Means
back slashes
218368 by: Daniel Baughman
218369 by: Jay Blanchard
Two websites need to share part of one database, suggestions please
218370 by: Chris W. Parker
218371 by: Robert Cummings
218374 by: Chris W. Parker
218375 by: Robert Cummings
file function
218372 by: Joseph Lee
218373 by: Ezra Nugroho
Apache 1.3x/PHP 5.0.3 404 error handler & posted data...
218376 by: Raymond C. Rodgers
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Thanks guys, getting some great recommendations... From what I hear, I
wont be using IpowerWeb, some people had nothing but good to say, but I
found quite a few more complaints then good.
eHostPros does sound very nice, I'll look into them as well.
Jason E.J. Manaigre
Web Site Development Coordinator | HTML God
International Institute for Sustainable Development
Winnipeg, Manitoba, Canada
Main Web site: http://www.iisd.org
Email: mailto:jmanaigreiisd.ca | Phone: 1.204.958.7744
-----Original Message-----
From: Terry Romine [mailto:terry_romineearthlink.net]
Sent: July 8, 2005 8:36 AM
To: php-generallists.php.net
Subject: Re: [PHP] Re: iPowerWeb ISP Are they good?
I had a client hosted on Powweb and I dropped that service pretty fast.
Now I host primarily on eHostPros.com (past 2-3 years). I've had a few
problems, but they work pretty close with the clients to handle issues.
Maybe a 90-95% satisfaction rate for me. The nice thing is their billing
system; they use PayPal and can charge monthly/quarterly/yearly as the
customer needs.
Terry
-----Original Message-----
From: chris <chrisjdata-trak.com>
Sent: Jul 7, 2005 4:51 PM
To: php-generallists.php.net
Subject: [PHP] Re: iPowerWeb ISP Are they good?
I have used iPowerWeb for a few years now and have only had "maybe" 5
min.
worth out outages. Even when I had a question on a Sunday, there was
someone
to answer the tech phone. It did take a while but still, its all good in
my
book.
Chris
""Jason Manaigre"" <jmanaigreiisd.ca> wrote in message
news:47AB1D483BC00940AC5DE54F9587ACAD0150F0C2proton.iisd.ca...
Hi everyone, currently I have a site hosted with Powweb and suffice it
to say, it's not good, so I wanted to get everyone's opinion here on
iPowerWeb? Or can you recommend another ISP that you swear by which has
similar features http://www.ipowerweb.com/products/webhosting/index.html
Thanks people.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
On 7/8/05, Ryan A <ryancoinpass.com> wrote:
> Yep, but this has no way of breaking my html....
If [/i] is missing, it'd be the same as </i> being missing.
I can just as easily clean out any missing </i> tags as I can any
missing [/i] tags.
--
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/
attached mail follows:
> > Yep, but this has no way of breaking my html....
>
> If [/i] is missing, it'd be the same as </i> being missing.
>
> I can just as easily clean out any missing </i> tags as I can any
> missing [/i] tags.
>
I am not really bothered about the closing tags (for example </i>)
I am more bothered about the opening closing tag (for example <i when it
should be <i>)
as this can mess up my page...but this cant do squat: [i
or this: i]
Cheers,
Ryan
attached mail follows:
On Jul 8, 2005, at 4:21 AM, <nick.telfordntlworld.com> wrote:
> Personally, I don't think it's a bad idea at all. The best way (and
> probably ONLY real way) to achieve decent security would be to limit
> the subset of tags the user can post. Best way to achieve this is to
> use your own tagging system (e.g. [p] instead of <p>) this will allow
> you to strip_tags to protect against injections and limit the tags the
> author can post (to protect against injection-through-conversion
> attacks).
>
> Use a pcre replace to replace all occurances of the allowed tags with
> the HTML equivilents upon page rendering (it's usually best to sore
> your tag format in the database instead of the raw HTML).
>
> As for SSL, is it really needed? The data would, in most cases, not be
> considered highly important. It would just leverage another server
> requirement on the end-user. If you're writing something for public
> consumption, it needs to be as flexible as possible.
>
> Besides, SSL has very little to do with PHP and is therefore not
> really worth thinking about. In order to include support for running
> the Administration of the CMS through SSL, simply allow the Admin
> pages to run on a different host.
>
> Last word, IP and User Agent tracking are more useless than MAC
> filtering on firewalls. In the long run, it'll simply add more
> overhead to your application and produce no useful information (unless
> you're using it purely for statistics).#
>
> PS: This is going through web-mail, so there's a good chance it might
> not reach the list.
Unless I'm really missing something important, for 'this' particular
part of the application, any BBCode/Tag stripping/rewriting
scheme would be useless since what they will be editing is the actual
templates that make the page, therefore all tags
would have to be allowed.
It's not the legitimate user I'm worried about doing something wrong,
it's that if it's possible for a legitimate user to do this,
then some "Bad Guy" somewhere "may" be able to do this too.
I've pretty much eliminated the possibility of someone using say cURL
or some other mechanism to post information
to the form processor directly. If they can guess two md5 hashes of two
different random numbers that may or may not
be set to allow the transaction as well as the ip/user agent associated
with one of the numbers, then nothing I do will
keep them out because they are GOD, or have a _lot_ of time on their
hands. Plus, the clients account will have more than
likely been shut down for going over their bandwidth quota from the
attempts.
[If I'm wrong in my assumptions here, someone please slap me in the
head]
What I'm worried about is someone grabbing a valid cookie id, and in
the short time-span that it _is_ valid, being able to
pull up the actual post form, which will then give them the second
number and the ip/user agent, and "legitimately"
posting malicious code. So yes, SSL is necessary at this point to try
to keep that cookie secret. If it can, which is what
I'm being paranoid about. This is a weak spot in the code "because" I
have to trust that the user is who they say they
are, all things considered. And at this point, I'm relying on SSL to be
the security "rock" that plugs up this hole.
Is SSL enough to keep the cookie safe?
Is it absolutely stupid to allow this, even if there will only ever be
one username/password combo that will be allowed
to access this part? Other parts of the admin console will be open to
other users though.
The actual web site, ie the pages created and maintained by the
application, is open to the public and there is no
SSL there, no cookies or info other than the html request/response of a
'normal' site.
Edward Vermillion
evermilliondoggydoo.net
attached mail follows:
On 7/8/05, Ryan A <ryancoinpass.com> wrote:
> I am not really bothered about the closing tags (for example </i>)
> I am more bothered about the opening closing tag (for example <i when it
> should be <i>)
> as this can mess up my page...but this cant do squat: [i
> or this: i]
That's where a good preview function comes in handy.
--
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/
attached mail follows:
I am just wondering, how could someone craft an html to steal cookies?
If your cookie distribution is done right, I don't think you need to
worry about this.
There are a gazillion of sites (CMS-based, wiki-based, etc, including
php.net) that allow users to contribute html. They are not concern about
security of data delivery.
I think, page breaking html is more prominent issue, which you could
eliminate with BBcode or wiki language.
Perhaps you are being a little paranoid?
Or do I miss something?
>
> Unless I'm really missing something important, for 'this' particular
> part of the application, any BBCode/Tag stripping/rewriting
> scheme would be useless since what they will be editing is the actual
> templates that make the page, therefore all tags
> would have to be allowed.
>
> It's not the legitimate user I'm worried about doing something wrong,
> it's that if it's possible for a legitimate user to do this,
> then some "Bad Guy" somewhere "may" be able to do this too.
>
> I've pretty much eliminated the possibility of someone using say cURL
> or some other mechanism to post information
> to the form processor directly. If they can guess two md5 hashes of two
> different random numbers that may or may not
> be set to allow the transaction as well as the ip/user agent associated
> with one of the numbers, then nothing I do will
> keep them out because they are GOD, or have a _lot_ of time on their
> hands. Plus, the clients account will have more than
> likely been shut down for going over their bandwidth quota from the
> attempts.
>
> [If I'm wrong in my assumptions here, someone please slap me in the
> head]
>
> What I'm worried about is someone grabbing a valid cookie id, and in
> the short time-span that it _is_ valid, being able to
> pull up the actual post form, which will then give them the second
> number and the ip/user agent, and "legitimately"
> posting malicious code. So yes, SSL is necessary at this point to try
> to keep that cookie secret. If it can, which is what
> I'm being paranoid about. This is a weak spot in the code "because" I
> have to trust that the user is who they say they
> are, all things considered. And at this point, I'm relying on SSL to be
> the security "rock" that plugs up this hole.
>
> Is SSL enough to keep the cookie safe?
>
> Is it absolutely stupid to allow this, even if there will only ever be
> one username/password combo that will be allowed
> to access this part? Other parts of the admin console will be open to
> other users though.
>
> The actual web site, ie the pages created and maintained by the
> application, is open to the public and there is no
> SSL there, no cookies or info other than the html request/response of a
> 'normal' site.
>
> Edward Vermillion
> evermilliondoggydoo.net
>
attached mail follows:
On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote:
>
> I am just wondering, how could someone craft an html to steal cookies?
> If your cookie distribution is done right, I don't think you need to
> worry about this.
>
That's what XSS is all about. I don't have the link handy but I do have
a PDF file that I found
a while back that explains how this happens, and to tell the truth, it
scared the s*** outa me.
To the point that I really don't trust any online commerce, although I
do still use it, just as
I still give the waitress/waiter my credit card at a restaurant, even
though I know that's where
most of the identity theft/stolen CC numbers comes from.
> There are a gazillion of sites (CMS-based, wiki-based, etc, including
> php.net) that allow users to contribute html. They are not concern
> about
> security of data delivery.
Yeah I know... :P
>
> I think, page breaking html is more prominent issue, which you could
> eliminate with BBcode or wiki language.
>
> Perhaps you are being a little paranoid?
> Or do I miss something?
>
So yeah, I'm being paranoid but I'm also trying to cover as many bases
as I can and yet
still provide some decent functionality.
Edward Vermillion
evermilliondoggydoo.net
attached mail follows:
On Jul 8, 2005, at 12:31 PM, Edward Vermillion wrote:
>
> On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote:
>
>>
>> I am just wondering, how could someone craft an html to steal cookies?
>> If your cookie distribution is done right, I don't think you need to
>> worry about this.
>>
>
> That's what XSS is all about. I don't have the link handy but I do
> have a PDF file that I found
> a while back that explains how this happens, and to tell the truth, it
> scared the s*** outa me.
> To the point that I really don't trust any online commerce, although I
> do still use it, just as
> I still give the waitress/waiter my credit card at a restaurant, even
> though I know that's where
> most of the identity theft/stolen CC numbers comes from.
Here's one of the links http://www.acros.si/papers/session_fixation.pdf
Edward Vermillion
evermilliondoggydoo.net
attached mail follows:
Here is one security measure that you HAVE to do if you allow people to
submit contents to your site.
1. track client's IP.
2. Associate sensitive cookies with the IP, if they don't match, ignore
it or invalidate the cookie.
We may not stop the information redirection.
We can make the information invalid.
Regards,
Ezra
On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote:
> On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote:
>
> >
> > I am just wondering, how could someone craft an html to steal cookies?
> > If your cookie distribution is done right, I don't think you need to
> > worry about this.
> >
>
> That's what XSS is all about. I don't have the link handy but I do have
> a PDF file that I found
> a while back that explains how this happens, and to tell the truth, it
> scared the s*** outa me.
> To the point that I really don't trust any online commerce, although I
> do still use it, just as
> I still give the waitress/waiter my credit card at a restaurant, even
> though I know that's where
> most of the identity theft/stolen CC numbers comes from.
>
> > There are a gazillion of sites (CMS-based, wiki-based, etc, including
> > php.net) that allow users to contribute html. They are not concern
> > about
> > security of data delivery.
>
> Yeah I know... :P
>
> >
> > I think, page breaking html is more prominent issue, which you could
> > eliminate with BBcode or wiki language.
> >
> > Perhaps you are being a little paranoid?
> > Or do I miss something?
> >
>
> So yeah, I'm being paranoid but I'm also trying to cover as many bases
> as I can and yet
> still provide some decent functionality.
>
>
> Edward Vermillion
> evermilliondoggydoo.net
>
attached mail follows:
On Jul 8, 2005, at 1:25 PM, Ezra Nugroho wrote:
>
> Here is one security measure that you HAVE to do if you allow people to
> submit contents to your site.
>
>
> 1. track client's IP.
> 2. Associate sensitive cookies with the IP, if they don't match, ignore
> it or invalidate the cookie.
>
> We may not stop the information redirection.
> We can make the information invalid.
>
Well, yes and no. If the "bad guy" can get the cookie, it's also likely
that he's got all the
information the valid user is sending you too, such as ip, user agent,
whatever...
So he's probably going to send all that along with the stolen cookie,
and the checks
you have will let him in.
All the ip, user agent, etc. checks do is slow down a brute-force
attack. They have to
guess more than one correct value to get in. But that cookie.... that's
the prize.
Edward Vermillion
evermilliondoggydoo.net
attached mail follows:
True. People can steal sessions within a firewall as well.
Unless if browsers can do digital signature, there is no a good way to
validate users.
I think you would agree that for now it comes down to two choices:
1. Focus on convenience, let security slack a little or
2. Focus on security, and tolerate some inconvenience.
W3C, please do something!!
On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote:
> I just was reading a thread on the PHPSEC list, where one of the developers
> of FUD Forums was (Ilia) was mentioning his experience with AOL users. He
> claims that IPs can change as frequently as every request to the server.
> I've also noted similar (but not as drastic) effects. IPs are really not a
> good fingerprint for a user, unless you are fine with invalidating users on
> a frequent basis
>
> Michael
>
> > -----Original Message-----
> > From: Ezra Nugroho [mailto:enugrohospikesource.com]
> > Sent: Friday, July 08, 2005 11:49 AM
> > To: Michael Caplan
> > Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia
> >
> > True, but it's better than nothing.
> >
> > IP doesn't change that often, maybe at worst once every hour.
> > Sensitive cookies should not live that long anyway.
> >
> > It's not a great solution, but it's something.
> >
> >
> >
> > On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote:
> > > IPs are unreliable. An ip will change frequently if a user travels
> > through
> > > a proxy pool, like AOL users, or just about any user from a large ISP.
> > >
> > > Michael
> > >
> > > > -----Original Message-----
> > > > From: Ezra Nugroho [mailto:enugrohospikesource.com]
> > > > Sent: Friday, July 08, 2005 11:25 AM
> > > > To: Edward Vermillion
> > > > Cc: php Lists
> > > > Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia
> > > >
> > > >
> > > > Here is one security measure that you HAVE to do if you allow people
> > to
> > > > submit contents to your site.
> > > >
> > > >
> > > > 1. track client's IP.
> > > > 2. Associate sensitive cookies with the IP, if they don't match,
> > ignore
> > > > it or invalidate the cookie.
> > > >
> > > > We may not stop the information redirection.
> > > > We can make the information invalid.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Ezra
> > > >
> > > >
> > > >
> > > > On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote:
> > > > > On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote:
> > > > >
> > > > > >
> > > > > > I am just wondering, how could someone craft an html to steal
> > cookies?
> > > > > > If your cookie distribution is done right, I don't think you need
> > to
> > > > > > worry about this.
> > > > > >
> > > > >
> > > > > That's what XSS is all about. I don't have the link handy but I do
> > have
> > > > > a PDF file that I found
> > > > > a while back that explains how this happens, and to tell the truth,
> > it
> > > > > scared the s*** outa me.
> > > > > To the point that I really don't trust any online commerce, although
> > I
> > > > > do still use it, just as
> > > > > I still give the waitress/waiter my credit card at a restaurant,
> > even
> > > > > though I know that's where
> > > > > most of the identity theft/stolen CC numbers comes from.
> > > > >
> > > > > > There are a gazillion of sites (CMS-based, wiki-based, etc,
> > including
> > > > > > php.net) that allow users to contribute html. They are not concern
> > > > > > about
> > > > > > security of data delivery.
> > > > >
> > > > > Yeah I know... :P
> > > > >
> > > > > >
> > > > > > I think, page breaking html is more prominent issue, which you
> > could
> > > > > > eliminate with BBcode or wiki language.
> > > > > >
> > > > > > Perhaps you are being a little paranoid?
> > > > > > Or do I miss something?
> > > > > >
> > > > >
> > > > > So yeah, I'm being paranoid but I'm also trying to cover as many
> > bases
> > > > > as I can and yet
> > > > > still provide some decent functionality.
> > > > >
> > > > >
> > > > > Edward Vermillion
> > > > > evermilliondoggydoo.net
> > > > >
> > > >
> > > > --
> > > > PHP General Mailing List (http://www.php.net/)
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > >
> > > CONFIDENTIALITY NOTICE
> > > This message contains confidential information intended only for the use
> > of
> > > the individual or entity named as recipient. Any dissemination,
> > distribution
> > > or copying of this communication by anyone other than the intended
> > recipient
> > > is strictly prohibited. If you have received this message in error,
> > please
> > > immediately notify us and delete your copy. Thank you.
> > >
> > > AVIS DE CONFIDENTIALITÉ
> > > Les informations contenues aux présentes sont de nature privilégiée et
> > > confidentielle. Elles ne peuvent être utilisées que par la personne ou
> > > l'entité dont le nom paraît comme destinataire. Si le lecteur du présent
> > > message n'est pas le destinataire prévu, il est par les présentes prié
> > de
> > > noter qu'il est strictement interdit de divulguer, de distribuer ou de
> > > copier ce message. Si ce message vous a été transmis par mégarde,
> > veuillez
> > > nous en aviser immédiatement et supprimer votre copie. Merci.
> > >
attached mail follows:
Okay:
From what I´ve read here, there seems to be a lot of useful
information - very litte of which is relevent to the question.
My understanding is that you(the OP) have a template-editing page,
which your designers can log into in order to edit the page, without
having ftp/sftp access?
It is reasonably possible to secure this, and you seem to have the
gist of what is necessary. In fact you seem a little paranoid(That´s a
good thing).
For a list of what to check and what not to check, one good place to
start would be to go through a PHP info page, pick out what is
useful(for verification) and leave behind what isn´t.
One possible step to secure against brute-force is to use captchas.
What you will have to ultimately accept, is that no matter how much
you secure a computer, it will never be completely secure - no matter
what.
On 7/8/05, Ezra Nugroho <enugrohospikesource.com> wrote:
>
> True. People can steal sessions within a firewall as well.
>
> Unless if browsers can do digital signature, there is no a good way to
> validate users.
>
> I think you would agree that for now it comes down to two choices:
> 1. Focus on convenience, let security slack a little or
> 2. Focus on security, and tolerate some inconvenience.
>
>
> W3C, please do something!!
>
>
>
> On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote:
> > I just was reading a thread on the PHPSEC list, where one of the developers
> > of FUD Forums was (Ilia) was mentioning his experience with AOL users. He
> > claims that IPs can change as frequently as every request to the server.
> > I've also noted similar (but not as drastic) effects. IPs are really not a
> > good fingerprint for a user, unless you are fine with invalidating users on
> > a frequent basis
> >
> > Michael
> >
> > > -----Original Message-----
> > > From: Ezra Nugroho [mailto:enugrohospikesource.com]
> > > Sent: Friday, July 08, 2005 11:49 AM
> > > To: Michael Caplan
> > > Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia
> > >
> > > True, but it's better than nothing.
> > >
> > > IP doesn't change that often, maybe at worst once every hour.
> > > Sensitive cookies should not live that long anyway.
> > >
> > > It's not a great solution, but it's something.
> > >
> > >
> > >
> > > On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote:
> > > > IPs are unreliable. An ip will change frequently if a user travels
> > > through
> > > > a proxy pool, like AOL users, or just about any user from a large ISP.
> > > >
> > > > Michael
> > > >
> > > > > -----Original Message-----
> > > > > From: Ezra Nugroho [mailto:enugrohospikesource.com]
> > > > > Sent: Friday, July 08, 2005 11:25 AM
> > > > > To: Edward Vermillion
> > > > > Cc: php Lists
> > > > > Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia
> > > > >
> > > > >
> > > > > Here is one security measure that you HAVE to do if you allow people
> > > to
> > > > > submit contents to your site.
> > > > >
> > > > >
> > > > > 1. track client's IP.
> > > > > 2. Associate sensitive cookies with the IP, if they don't match,
> > > ignore
> > > > > it or invalidate the cookie.
> > > > >
> > > > > We may not stop the information redirection.
> > > > > We can make the information invalid.
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ezra
> > > > >
> > > > >
> > > > >
> > > > > On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote:
> > > > > > On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote:
> > > > > >
> > > > > > >
> > > > > > > I am just wondering, how could someone craft an html to steal
> > > cookies?
> > > > > > > If your cookie distribution is done right, I don't think you need
> > > to
> > > > > > > worry about this.
> > > > > > >
> > > > > >
> > > > > > That's what XSS is all about. I don't have the link handy but I do
> > > have
> > > > > > a PDF file that I found
> > > > > > a while back that explains how this happens, and to tell the truth,
> > > it
> > > > > > scared the s*** outa me.
> > > > > > To the point that I really don't trust any online commerce, although
> > > I
> > > > > > do still use it, just as
> > > > > > I still give the waitress/waiter my credit card at a restaurant,
> > > even
> > > > > > though I know that's where
> > > > > > most of the identity theft/stolen CC numbers comes from.
> > > > > >
> > > > > > > There are a gazillion of sites (CMS-based, wiki-based, etc,
> > > including
> > > > > > > php.net) that allow users to contribute html. They are not concern
> > > > > > > about
> > > > > > > security of data delivery.
> > > > > >
> > > > > > Yeah I know... :P
> > > > > >
> > > > > > >
> > > > > > > I think, page breaking html is more prominent issue, which you
> > > could
> > > > > > > eliminate with BBcode or wiki language.
> > > > > > >
> > > > > > > Perhaps you are being a little paranoid?
> > > > > > > Or do I miss something?
> > > > > > >
> > > > > >
> > > > > > So yeah, I'm being paranoid but I'm also trying to cover as many
> > > bases
> > > > > > as I can and yet
> > > > > > still provide some decent functionality.
> > > > > >
> > > > > >
> > > > > > Edward Vermillion
> > > > > > evermilliondoggydoo.net
> > > > > >
> > > > >
> > > > > --
> > > > > PHP General Mailing List (http://www.php.net/)
> > > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > > >
> > > >
> > > > CONFIDENTIALITY NOTICE
> > > > This message contains confidential information intended only for the use
> > > of
> > > > the individual or entity named as recipient. Any dissemination,
> > > distribution
> > > > or copying of this communication by anyone other than the intended
> > > recipient
> > > > is strictly prohibited. If you have received this message in error,
> > > please
> > > > immediately notify us and delete your copy. Thank you.
> > > >
> > > > AVIS DE CONFIDENTIALITÉ
> > > > Les informations contenues aux présentes sont de nature privilégiée et
> > > > confidentielle. Elles ne peuvent être utilisées que par la personne ou
> > > > l'entité dont le nom paraît comme destinataire. Si le lecteur du présent
> > > > message n'est pas le destinataire prévu, il est par les présentes prié
> > > de
> > > > noter qu'il est strictement interdit de divulguer, de distribuer ou de
> > > > copier ce message. Si ce message vous a été transmis par mégarde,
> > > veuillez
> > > > nous en aviser immédiatement et supprimer votre copie. Merci.
> > > >
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
On Sat, 2005-05-14 at 19:34 -0700, Richard Lynch wrote:
> On Fri, October 14, 2005 11:33 am, Cima said:
> > i have my web site working something like this: in every php script i have
> > require(auth.php). this auth.php has my connection to my postgresql server
> > and database along with some other stuff i need for the user to be
> > authenticated to my web site. when i log on, this auth.php connects to the
> > dbserver and checks if my username and password are stored and then i go
> > to a home page. my connection is stored in $dbh.
> > what happens when i start moving through all these web pages (php
> > scripts), each requires auth.php, with respect to the connection? is a new
> > connection established for every web page i go into that uses my $dbh for
> > querying purposes or is it the same connection i originally made when i
> > first logged into the web site?
>
> You'll get a new connection on each page.
>
> Which is good, because database connections CANNOT be shared across page
> hits.
>
> If you use _pconnect, you can get a "refurbished" connection from the
> database instead of a truly new one. But there are "gotchas" with that,
> and I wouldn't recommend you jump into that without a lot more
> research/experience.
>
> I would suggest, however, that you put the database connection in a
> totally separate file from the auth.php, and require them separately.
>
> You may find more uses for your database some day, maybe even for pages
> that do NOT require authentication, and you'll more easily do that if you
> can just do:
> <?php require 'db_connect.php';?>
>
> For the pages that need authentication, you'd do:
> <?php
> require 'db_connect.php';
> require 'auth.php';
> ?>
-- Better yet:
file auth.php:
require_once 'db_connect.php';
Ever since discovering the [require|include]_once I have wondered how I
managed before...
Hope this helps
-- Jeff
> You could also look into http://php.net/require_once, but I tend to find
> that people who start off with that end up being sloppy coders and end up
> having a whole rats' nest of includes with no real Plan behind them, which
> cause problems in the long run. Just my opinion, and I'm bound to take
> flak for it.
>
> --
> Like Music?
> http://l-i-e.com/artists.htm
>
--
Jeffrey D. Means meajemeanspc.com
Owner / CIO for MeansPC http://www.meanspc.com/
Custom Web Development For Your Needs. (970)308-1298
- The stupidity of a stupid person is exercised in a restricted
field; the stupidity of an intelligent individual has a much broader
diffusion, and far greater effect, aided as it is by the element
of surprise.
- WTO + WIPO = DMCA? http://www.anti-dmca.org
- Fight Internet Censorship! http://www.eff.org
= This is not about Napster or DVDs. It's about your Freedom.
http://www.anti-dmca.org
My Public PGP Key ID is: 0x81F00126
and available via:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x81F00126
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBCzsS0Swct1IHwASYRAraxAJwND9GLOHB0XZuVd27CQYRoRYx6cACggJ3r
fDOc4CBrfSKt8LwcCLtC1kw=
=RApk
-----END PGP SIGNATURE-----
attached mail follows:
Hello all,
I’m attempting to insert a windows path into a mysql database via PHP, but
it keeps ineterpreting the backslashes as escape chars.
Lets say I have a string:
"c:\www\test"
I want to insert it into a database, but what ends up getting inserted is:
c:wwwtest
I can not get php to double the back slashes no matter what I do!
$string = str_replace("\\", "\\\\", $string);
That is what I want to do, get all single '\' into double '\\'...
Any suggestions?
attached mail follows:
[snip]
Lets say I have a string:
"c:\www\test"
I want to insert it into a database, but what ends up getting inserted
is:
c:wwwtest
I can not get php to double the back slashes no matter what I do!
$string = str_replace("\\", "\\\\", $string);
That is what I want to do, get all single '\' into double '\\'...
Any suggestions?
[/snip]
http://www.php.net/addslashes
attached mail follows:
Hello,
We have two websites. One website is already up and running, the other
is not.
The first website (I'll call it one.com) contains a large number of the
products and is meant for a specific audience. The second website (I'll
call it, yep you guessed it, two.com) will contain a small subset of the
products that are currently available on one.com. It is meant for a
different audience.
Since two.com will have a subset of the products found on one.com I'm
not sure which method of duplicating the data is the best.
Here are some options I've come up with to handle this:
1. Create two completely different databases where a pricing update in
one database will need to be made in the other database. This process
would either be done manually or automatically through a cron job.
PROS: Data integrity is almost nill since each records autonumber id
will be based upon its own data and not old data from another db.
CONS: A robust script will need to be created that can determine which
db's data should be copied or not copied. e.g. Let's say I update the
price for one of the products. That's an easy one because whichever
record has the latest price_modified time wins. But then let's say I
modify the description to include some promotional text for website
two.com that I don't want to show up on website one.com? I either need
to always ignore data like 'description', 'name', etc. or come up with
some complicated way of telling the update script not to include certain
changes. Complicated!
2. Create a new database with all the same structure as the original
database except that it will not contain a products table. The product
information will be retrieved from the original database.
PROS: Data comes from only one place.
CONS: Data integrity. What if a change happens in the original database
that adversely affects the second? (I can't think of any examples at the
moment.) Another con is that each product must have exactly the same
data. I can't add promotional text to a product meant only for a
specific website and leave it off the other website.
3. Add extra tables for the new website to the original database by
prefixing a delimiter to each table.
PROS: One database.
CONS: This just seems more kludgy than the rest of them.
e.g.
Original db without modifications:
products
customers
categories
etc.
Now with new website tables:
products
two_products
customers
two_customers
categories
two_categories
etc.
4. Add a field to each table that will differentiate which website the
record belongs to. e.g. 'SELECT * FROM orders WHERE website = 2'.
Now that I'm thinking about it, this option seems to ultimately be the
same as #1. I can't think of any inherent benefits to this option.
Which option should I go for? Is there another option I'm not
considering?
Thanks!
Chris.
attached mail follows:
On Fri, 2005-07-08 at 18:20, Chris W. Parker wrote:
> Hello,
>
> We have two websites. One website is already up and running, the other
> is not.
>
> The first website (I'll call it one.com) contains a large number of the
> products and is meant for a specific audience. The second website (I'll
> call it, yep you guessed it, two.com) will contain a small subset of the
> products that are currently available on one.com. It is meant for a
> different audience.
>
> Since two.com will have a subset of the products found on one.com I'm
> not sure which method of duplicating the data is the best.
>
> Here are some options I've come up with to handle this:
>
> 1. Create two completely different databases where a pricing update in
> one database will need to be made in the other database. This process
> would either be done manually or automatically through a cron job.
>
> PROS: Data integrity is almost nill since each records autonumber id
> will be based upon its own data and not old data from another db.
>
> CONS: A robust script will need to be created that can determine which
> db's data should be copied or not copied. e.g. Let's say I update the
> price for one of the products. That's an easy one because whichever
> record has the latest price_modified time wins. But then let's say I
> modify the description to include some promotional text for website
> two.com that I don't want to show up on website one.com? I either need
> to always ignore data like 'description', 'name', etc. or come up with
> some complicated way of telling the update script not to include certain
> changes. Complicated!
>
> 2. Create a new database with all the same structure as the original
> database except that it will not contain a products table. The product
> information will be retrieved from the original database.
>
> PROS: Data comes from only one place.
>
> CONS: Data integrity. What if a change happens in the original database
> that adversely affects the second? (I can't think of any examples at the
> moment.) Another con is that each product must have exactly the same
> data. I can't add promotional text to a product meant only for a
> specific website and leave it off the other website.
>
> 3. Add extra tables for the new website to the original database by
> prefixing a delimiter to each table.
>
> PROS: One database.
> CONS: This just seems more kludgy than the rest of them.
>
> e.g.
>
> Original db without modifications:
>
> products
> customers
> categories
> etc.
>
> Now with new website tables:
>
> products
> two_products
> customers
> two_customers
> categories
> two_categories
> etc.
>
> 4. Add a field to each table that will differentiate which website the
> record belongs to. e.g. 'SELECT * FROM orders WHERE website = 2'.
>
> Now that I'm thinking about it, this option seems to ultimately be the
> same as #1. I can't think of any inherent benefits to this option.
>
>
> Which option should I go for? Is there another option I'm not
> considering?
Use a bitvector field in the table and use a bitmask for filtering for
which sites can access what products. Then similarly for customizations
(presuming good database normalization) you can extend this to
customizations, specials, etc, etc. This is only one possible solution
of many, you could have the database list in another table, but I
thought I'd skip a join since you only mention two sites.
Pros:
- great data integrity
- single point of update
Cons:
- using bits (if that's really a con :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
attached mail follows:
Robert Cummings <mailto:robertinterjinn.com>
on Friday, July 08, 2005 3:32 PM said:
> Use a bitvector field in the table and use a bitmask for filtering for
> which sites can access what products.
I think I understand what a bitmask is after doing some research but
would you please give me an example so I can apply what I've read?
> Then similarly for
> customizations (presuming good database normalization) you can extend
> this to customizations, specials, etc, etc. This is only one possible
> solution of many, you could have the database list in another table,
> but I thought I'd skip a join since you only mention two sites.
Again, I think I understand what you're suggesting, but the problem is
that I'm not sure how to apply it. Example please, if you will.
Thanks,
Chris.
attached mail follows:
On Fri, 2005-07-08 at 19:46, Chris W. Parker wrote:
> Robert Cummings <mailto:robertinterjinn.com>
> on Friday, July 08, 2005 3:32 PM said:
>
>
> > Use a bitvector field in the table and use a bitmask for filtering for
> > which sites can access what products.
>
> I think I understand what a bitmask is after doing some research but
> would you please give me an example so I can apply what I've read?
>
> > Then similarly for
> > customizations (presuming good database normalization) you can extend
> > this to customizations, specials, etc, etc. This is only one possible
> > solution of many, you could have the database list in another table,
> > but I thought I'd skip a join since you only mention two sites.
>
> Again, I think I understand what you're suggesting, but the problem is
> that I'm not sure how to apply it. Example please, if you will.
An over simplification :)
$site1 = 1;
$site2 = 2;
$currSite = $site2;
$qString =
"SELECT "
." * "
."FROM "
." products "
."WHERE "
." id = ".addSlashes( $someId )." "
." AND "
." siteMask & ".(1 << $currSite)." ";
Note that the query uses boolean & and not logical && which allows it to
match individual bits.
Thus siteMask should have one of the following values:
(1 << 1) == 2 // only site1 can use the product.
(1 << 2) == 4 // only site2 can use the product.
((1 << 1) | (1 << 2)) == 6 // both sites can use the product.
HTH,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
attached mail follows:
Hi,
I tried file() in the following lines:
<?php
$authFile = file("/tmp/authenticate.txt");
print "authFile = $authFile";
?>
However, it only gave me
authFile = Array
What's wrong with this file function? I tried single
quotes, but got the same answer, too.
Thanks,
Joe
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/
attached mail follows:
Well, it supposed to give you array.
http://us2.php.net/manual/en/function.file.php
array file ( string filename [, int use_include_path [, resource
context]] )
What do you want exactly?
Ezra
On Fri, 2005-07-08 at 16:34 -0700, Joseph Lee wrote:
> Hi,
>
> I tried file() in the following lines:
>
> <?php
> $authFile = file("/tmp/authenticate.txt");
> print "authFile = $authFile";
> ?>
>
> However, it only gave me
> authFile = Array
>
> What's wrong with this file function? I tried single
> quotes, but got the same answer, too.
>
> Thanks,
> Joe
>
>
>
> ____________________________________________________
> Sell on Yahoo! Auctions – no fees. Bid on great items.
> http://auctions.yahoo.com/
>
attached mail follows:
I'm trying to write an error handler in PHP to try to avoid sending the
browser a 404 error message. Basically, if someone
requests /whatever.html on the server and it doesn't exist, my 404 error
handler checks to see if /whatever.php exists, if so, it then includes
that file.
That part works fine.
The part that I'm having trouble with is if /whatever.html happens to be
the target of a form POST. With GET requests, the data is available in
either $_SERVER['REDIRECT_QUERY_STRING'] or (worst case)
$_SERVER['REQUEST_URI']. That's easy enough to parse and turn into
$_REQUEST and/or $_GET. However, it seems that POSTed data just vanishes
into thin air. $_POST is not set, of course, and I've been trying to
read data using file_get_contents('php://input') but nothing is
returned... Is this a bug in PHP, Apache, not a bug but an unimplemented
feature, security precaution, or what? Am I missing something simple to
get the POSTed data?
Thank you,
Raymond
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]