OSEC

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 1 Mar 2005 20:25:49 -0000 Issue 3313

php-general-digest-helplists.php.net
Date: Tue Mar 01 2005 - 14:25:49 CST


php-general Digest 1 Mar 2005 20:25:49 -0000 Issue 3313

Topics (messages 209671 through 209732):

Re: How to handle actions that may take a long time?
        209671 by: Cajus Pollmeier
        209672 by: Cajus Pollmeier
        209695 by: Bret Hughes

Re: HTTP Include Error
        209673 by: AdamT

problem with mail()
        209674 by: Stefan Sturm

Re: problem with mail() and attachment
        209675 by: AdamT

Re: Semi-OT: Anti-password trading/sharing solutions
        209676 by: AdamT
        209684 by: Dan Trainor
        209687 by: Mikey
        209688 by: Jochem Maas
        209691 by: Dan Trainor
        209693 by: Mikey
        209694 by: Jochem Maas
        209697 by: Dan Trainor
        209698 by: Mikey
        209732 by: Richard Lynch

Re: problems with several JPEGs in GD2
        209677 by: AdamT
        209678 by: anirudh dutt
        209679 by: AdamT
        209680 by: anirudh dutt

PHP 4.3.10 and Apache2.0 with MPM
        209681 by: Info.Best-IT

php-help
        209682 by: K Karthik
        209686 by: Burhan Khalid

Re: PHP slowness
        209683 by: Gerard

Re: _POST not working (using mini_httpd) - 2 attachments
        209685 by: Burhan Khalid

Re: textarea posting duplicate text
        209689 by: Elizabeth Lawrence
        209703 by: Bret Hughes
        209707 by: Bret Hughes
        209718 by: Dan Tappin
        209719 by: John Holmes

Re: On Topic - Theoretical Concents of Anti-password trading/sharing solutions
        209690 by: tg-php.gryffyndevelopment.com
        209692 by: Dan Trainor
        209696 by: Robert Cummings
        209701 by: John Nichel
        209702 by: Dan Trainor

mcrypt_create_iv always returns same value?
        209699 by: Murray . PlanetThoughtful
        209725 by: Richard Lynch

Spam and this list
        209700 by: bob
        209705 by: Richard Davey

Re: Inline Frame and php
        209704 by: Joe Harman
        209706 by: Mikey
        209730 by: Joe Harman

How can I send a gif picture to the mobile client via php?
        209708 by: Å£À¤
        209710 by: Mikey
        209724 by: Richard Lynch
        209731 by: Richard Lynch

Re: Like ternary but without the else.
        209709 by: Chris W. Parker

(O-T) PHP developer position available
        209711 by: Radu Filip

Program flow?
        209712 by: rory walsh
        209714 by: Richard Davey
        209723 by: Richard Lynch
        209729 by: Jason Barnett

mysql problems
        209713 by: Jed R. Brubaker
        209721 by: Richard Lynch
        209722 by: Rory McKinley

Re: Pop-up message
        209715 by: hitek.cox.net

combining values
        209716 by: William Stokes
        209717 by: Sascha Kaufmann
        209720 by: Bret Hughes
        209726 by: Leif Gregory
        209727 by: Leif Gregory

Re: Authentication fails
        209728 by: Jason Barnett

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:


Am Dienstag, 1. März 2005 01:24 schrieb Richard Lynch:
> Cajus Pollmeier wrote:
> > I'd like to know your opinion about how to handle events that may take
> > more than a minute to finish in PHP. In this case, the code is
> > performing a recursive action on a large LDAP tree where I'd like to
> > present something like a status page ("Please wait, blah blah" with
> > some animated gif or so), while the action takes place in background.
> >
> > Is it possible to fork away this PHP code and set some SESSION vars to
> > trigger the end of the status page? Or do I have to put this action
> > behind a one pixel image and act when the page is "really" complete?
> > Also I'm not sure how to handle the script execution timeout problem...
>
> Do you really expect the user wants to sit there for all the time waiting
> for the process to finish?

Yes. Should be the case, because later actions would depend on a changed data
set. In this case I'm renaming entries of a complete subtree. This may last a
long time and should not be abortable in any way. While this may change the
data the user is working on, he/she should wait till it is completed.

> Is there ANY way to factor out that code and do it before they get there?
> Obviously not for a search where the user types in what they want, but is
> that what you are doing? You don't say; I can't guess.

See above.

> Basically, if I have to sit there waiting, then I'm not really all that
> impressed with an animated gif or whatever...

Not you. But most people are not impressed by a spinning gear, globe or
whatever your browser shows up.

> Perhaps you have them logged in already, and you could record their search
> parameters and assign it an ID, and perform the search in the background,
> and then have a page to deliver the results to later.

I'm not sure how I could fork away a PHP process to be not interruptible, or
behave like you're writing above.

Just thinking about a session thingie. Place a little iframe on the page which
reloads once a second and check a session variable if we're finished. If we
are, reload the parent page.

Thanks,
Cajus

attached mail follows:


Am Dienstag, 1. März 2005 09:14 schrieb listasuakari.com:
> You can send a piece of HTML defining some little thing like a div layer
> with your "please wait, bla bla bla...."
> So the visitor can read something.
> When the process is finished, you can write another piece of HTML
> containing some JavaScript lines, changing the text (and icons or
> images) so you can inform your visitor that the process had finished.

If it's possible I'd like to avoid js ;-)

> This is the clasical no end web page... You can do something similar
> with frames, so in a little frame the visitor can see the status,
> (searching, wait...) and in another big frame can do something usefull.

I'm going to evaluate some things...

Thanks,
Cajus

attached mail follows:


On Tue, 2005-03-01 at 03:05, Cajus Pollmeier wrote:
> Am Dienstag, 1. März 2005 09:14 schrieb listasuakari.com:
> > You can send a piece of HTML defining some little thing like a div layer
> > with your "please wait, bla bla bla...."
> > So the visitor can read something.
> > When the process is finished, you can write another piece of HTML
> > containing some JavaScript lines, changing the text (and icons or
> > images) so you can inform your visitor that the process had finished.
>
> If it's possible I'd like to avoid js ;-)
>
> > This is the clasical no end web page... You can do something similar
> > with frames, so in a little frame the visitor can see the status,
> > (searching, wait...) and in another big frame can do something usefull.
>
> I'm going to evaluate some things...
>

I don't know where I read it but there are some ideas out there that
people use to monitor long running html uploads and provide status on
them. IIRC the main idea was to write the status to a file ( or like
you said, to a session var) and periodically reload the page to get the
latest status. Now that I think about it it may have been a how to do a
status bar for uploads. I do not recall if it needed js or not.

HTH
Bret

attached mail follows:


On Mon, 28 Feb 2005 15:35:36 -0700, Suhas <psuhasgmail.com> wrote:
> Hi
>
> This issue has been discusses many times before, but no perticular
> solution found.
>
Things to check when 'including' with http:

i) Can the server resolve the host name? Eg - if, from the server,
you run 'ping host.example.com, will it resolve this to an IP address?
ii) Can the server connect to that IP address on port 80?
iii) Are you marking up files and directories properly? /example.php
is a file, whereas /example.php/ is a directory (note the forwardslash
on the end).
iv) Is the file-system case-sensitive? Might
example.com/thingy/index.php be different to
example.com/THINGY/Index.PHP ? This is more likely on UNIX
filesystems.
v) Are you trying to connect with HTTP/1.1 to a server which only
understands HTTP/1.0 ?
vi) Is there something in the path which might be causing the problems
with php? Eg - special characters which would need to be \'escaped\'.
 This is a particular nuisance when connecting to IIS boxen which
don't have the default domain configured, so you have to give a
username in the format of DOMAIN\username.
vii) You *did* plug that network cable back in, didn't you?
viii) The file does actually exist, doesn't it? Try GETing the URL
manually with telnet:
telnet example.com 80
GET /uri/of/file.php HTTP/1.0
Host: example.com
<CR/LF><CR/LF>

And see what you get back. You'll either get the page contents sent
to you, or a 404 (This file isn't here), or maybe you'll get a 302
(Object has moved). A 302 looks like this in the headers:

HTTP/1.0 302 Found
Location: /newlocation

If you look at it in a browser, you'll be taken to the new location,
and probably won't notice that anything was ever wrong. If you try to
'include' from that path, it'll fail.

--
AdamT
"Justify my text? I'm sorry, but it has no excuse."

attached mail follows:


Hi,

I'm using the script below to send ascii files attached to mails via mail().
I'm running the script on different servers and it works fine. Now I got a
problem on windows server 2003. The attachment of the mail is disturbed, the
first 76 characters are missing, the rest of the attachment is correct. When
I looked at the mail headers of the mail I recieved I recognized that there
were some lines missing. Also the first line of the attachment part in the
header is mssing. As I use chunk_split without the chunklen paramter the
lines are all 76 characters long. So it just looks like that the server
ommits lines in the header. I marked the missing lines in the script with
comments. Has anybody got an idea where the problem could be?

Thank in advance

Stefan

  $unique_sep =md5(uniqid(time()))";
  $headers = "From: egrade questionaire\n";
  $headers .= "MIME-Version: 1.0\nContent-Type:
multipart/mixed;boundary=\"$unique_sep\";\n";

#The second \n at the end of the next command is ommited, the resulting
empty line is not in the header of the received mail
  $headers .= "charset=\"iso-8859-1\"\nContent-Transfer-Encoding:7bit\n\n";
  $headers .= "egrade-result\n";
  $headers .= "If you read this text your mail server is not supporting MIME
Format.\n";
  $headers .= "--$unique_sep\n";
  $headers .= "Content-Type: text/plain; charset=\"iso-8859-1\"\n";
#The second \n at the end of the next command is ommited, the resulting
empty line is not in the header of the received mail
   $headers .= "Content-Transfer-Encoding: 7bit\n\n";
#From the next command only a single \n is in the header of the received
mail, the text and the other \n are missing
  $headers .= "egrade-result\n\n";
  $headers .= "--$unique_sep\n";
# filename holds the path to the ascii file
  $headers .= "Content-Type: {text/plain}; name=\"{$filename}\"\n";
  $headers .= "Content-Transfer-Encoding: base64\n";
  $headers .= "Content-Disposition: attachment\n\n";
  $filedata = implode(file($filename), '');
  $headers .= chunk_split(base64_encode($filedata));
  $headers .= "--$unique_sep--\n";
  if(mail("stssoucon.de","subject","egrade-result",$headers) or die("An
error occured! The questionnaire has not been processed"));

attached mail follows:


On Sun, 27 Feb 2005 08:23:26 +0100, Stefan Sturm <stssoucon.de> wrote:
> Hi,
>
> I'm using the script below to send ascii files attached to mails via mail().
snip
> Has anybody got an idea where the problem could be?
>
It appears that your mailserver has developed a fault and is sending
all messages out two or three times.
--
AdamT
"Justify my text? I'm sorry, but it has no excuse."

attached mail follows:


On Mon, 28 Feb 2005 15:42:37 -0800 (PST), Richard Lynch <ceol-i-e.com> wrote:
> I know absolutely nothing about how ProxyPass, iProtect, and PureMember
> work

'Pure'member seems such an odd choice of name for something used on pr0n sites.

--
AdamT
"Justify my text? I'm sorry, but it has no excuse."

attached mail follows:


AdamT wrote:
> On Mon, 28 Feb 2005 15:42:37 -0800 (PST), Richard Lynch <ceol-i-e.com> wrote:
>
>>I know absolutely nothing about how ProxyPass, iProtect, and PureMember
>>work
>
>
> 'Pure'member seems such an odd choice of name for something used on pr0n sites.
>

This product is not marketed exclusively for 'pr0n' sites.

I'm not really sure if it matters what you think of the name of a
product, ever. Wait, nope. It doesn't. Not at all.

I obviously pissed off many people for asking a simple question. Some
of the feedback I've gotten was completely uncalled for, and many of you
responded in a less than professional manner. However, those of you
that did respond in a professional manner, I greatly appreciate your
feedback.

I'm not trying to tell anyone that the industry that I work for is
ideal, and they should love it. Unfortunately, some people think that
this is what I was saying. The only thing that I can say to you few
people is to sod off. You're not making anyone else angry except for
yourselves.

This list is a very valuable resource to me. I enjoy PHP a lot, but I
do get stuck on occasion, and when I ask a question to the list, I know
that I can get the very best of help because there are some very clever
people on this list. With that being said, I thought I'd go ahead and
ask my original question, expecting clever answers from clever people.

I'm not going to defend my industry or advocate my trade. However, I am
going to personally apologize for pissing so many people off. This was
clearly not my intent.

Thanks for the time
-dant

attached mail follows:


[snip everything irrelevant]

On a tehnical note, I don't really see how you can prevent this sharing of
logins. This is something I was actually looking into for a site that had
nothing to do with pr0n (would love to know where that came from, it seems
so universal now).

If you read up on the general issues surrounding client identification
(http://phpsec.org) it is pretty much impossible to come up with a solution
of uniquely identifying a specific browser session that will work in all
instances. And really, this is what you are trying to get at isn't it?
Uniquely identifying your clients.

The only non-technical solution I can offer you is that you change the
passwords for each person as they login. This would make people much more
reluctant to shre their account as they would not be able to access their
own account as soon as someone else logs in with it.

Of course, people aren't gonna like have to remember all the different
passwords but I think it helps with your problem.

As for the rest of this whole thread, I think we should all be a little more
"live and let live" about this. So you don't like pr0n? So what? I know a
lot of people who do (not so much myself, am more of a doer) but I don't
think it makes them bad people. I also happen to know that not all pr0n is
about exploitation. Some is, of course, and I'm sure that even Dan would
agree that this is not good - if anyone had bothered to find out in the
first place.

I'm not trying to invite more flaming here - there have been some very valid
points made, I just hope this thread can die a quick and silent death not
that the technical issue has been addressed.

Mikey

attached mail follows:


Hi Mikey,

you writing is very balanced, nicely put... I very much
agree with the position you take/have (maybe my OP didn't put
it quite so clearly ;-)

but you write that Dan probably agrees that (any) exploitation
(that occurs) is a bad thing... a logical assumption.... now read
this a weep (it a offlist reply from Dan to a reply of mine to his reply
original reply to my OP), It really shows what a kind, caring guy Dan
is:

<quote>
I do understand your points. Being in this industry, you're not the first person who I've met that dislikes the idea of
what I do. There's nothing more that I can do aside from telling you to, well basically, fuck off. I see people like
you on a daily basis, and unfortunately they confront me about the "situation". Most of the time I kindly just ignore them.

I do what I do because I understand the market, the Webmasters, and the customers. I have a wonderful company. My
employees like what they do. I like what I do. I love it. If you are trying to tell me that I'm a bad person for
making a buck off of some slut who needs to pay rent for a month, then so be it. I don't care. I only host these sites
and make sure that they stay online. I don't have to deal with any of the "models". I could give two shits and a
giggle what they go through. It was their choice to result to pornography - not mine. I could, again, give two shits
and a giggle what society thinks of them, myself, or my business. It would be silly and foolish to try to change the
minds of anyone that has anything to do with this industry. The same level of foolishness that you are suggesting by
telling me that I am a bad person...

The best I can tell you is to ignore what you don't like, because your views, as extensive and expressive as they are,
will always fall on deaf ears. I'm sorry.

With that being said, I cannot continue this conversation. I would continue it if my time was worth it and you did not
take an offensive manner to the situation.

Good luck with your church.

Thanks
-dant
</quote>

Mikey wrote:
> [snip everything irrelevant]
>

...

> think it makes them bad people. I also happen to know that not all pr0n is
> about exploitation. Some is, of course, and I'm sure that even Dan would
> agree that this is not good - if anyone had bothered to find out in the
> first place.

...

attached mail follows:


Jochem Maas wrote:
> Hi Mikey,
>
> you writing is very balanced, nicely put... I very much
> agree with the position you take/have (maybe my OP didn't put
> it quite so clearly ;-)
>
> but you write that Dan probably agrees that (any) exploitation
> (that occurs) is a bad thing... a logical assumption.... now read
> this a weep (it a offlist reply from Dan to a reply of mine to his reply
> original reply to my OP), It really shows what a kind, caring guy Dan
> is:
>
>
> <quote>
> I do understand your points. Being in this industry, you're not the
> first person who I've met that dislikes the idea of what I do. There's
> nothing more that I can do aside from telling you to, well basically,
> fuck off. I see people like you on a daily basis, and unfortunately
> they confront me about the "situation". Most of the time I kindly just
> ignore them.
>
> I do what I do because I understand the market, the Webmasters, and the
> customers. I have a wonderful company. My employees like what they
> do. I like what I do. I love it. If you are trying to tell me that
> I'm a bad person for making a buck off of some slut who needs to pay
> rent for a month, then so be it. I don't care. I only host these sites
> and make sure that they stay online. I don't have to deal with any of
> the "models". I could give two shits and a giggle what they go
> through. It was their choice to result to pornography - not mine. I
> could, again, give two shits and a giggle what society thinks of them,
> myself, or my business. It would be silly and foolish to try to change
> the minds of anyone that has anything to do with this industry. The
> same level of foolishness that you are suggesting by telling me that I
> am a bad person...
>
> The best I can tell you is to ignore what you don't like, because your
> views, as extensive and expressive as they are, will always fall on deaf
> ears. I'm sorry.
>
> With that being said, I cannot continue this conversation. I would
> continue it if my time was worth it and you did not take an offensive
> manner to the situation.
>
> Good luck with your church.
>
> Thanks
> -dant
> </quote>
>
>
>
>
> Mikey wrote:
>
>> [snip everything irrelevant]
>>
>
> ...
>
>> think it makes them bad people. I also happen to know that not all
>> pr0n is
>> about exploitation. Some is, of course, and I'm sure that even Dan would
>> agree that this is not good - if anyone had bothered to find out in the
>> first place.
>
>
> ...
>

I don't think that this is an issue that is specific to pr0n. Sure, the
first thing that we think of when we hear a traded login is actually
pr0n, but it is most definately not limited to this arena.

I appreciate the kind words mentioned by Jochem and Mikey. They see
through the whole stereotypical "I have a username and password" thing
and understand the true technical reasoning behind my question.

To address Mikey's question - I am not looking for a way to uniquely
identify users. For one, it's just not possible. On top of that, the
vast majority of members with to stay anonymous for reasons that I am
not even going to begin to state on this list, because we all know where
that will end up.

I am trying to ensure that one login and one password are specific to
one client. Several methods of this include making sure that not more
than two IPs use a specific login/password throughout a pre-set
threshold, and on top of this, the automatic blocking of IPs that
attempt brute-force style attacks. These two items alone would be an
invaluable tool in the assurance that logins and passwords are not abused.

Thanks again
-dant

attached mail follows:


> To address Mikey's question - I am not looking for a way to
> uniquely identify users. For one, it's just not possible.
> On top of that, the vast majority of members with to stay
> anonymous for reasons that I am not even going to begin to
> state on this list, because we all know where that will end up.

I think you have misunderstood me - I mean't uniquely identifying *clients*
- browsers.

> I am trying to ensure that one login and one password are
> specific to one client. Several methods of this include
> making sure that not more than two IPs use a specific
> login/password throughout a pre-set threshold, and on top of
> this, the automatic blocking of IPs that attempt brute-force
> style attacks. These two items alone would be an invaluable
> tool in the assurance that logins and passwords are not abused.

As I say, have a look at phpsec.org - the article on sessions is what you
want, and it will explain why doing something like that will not work as
expected. Some proxies assign new IPs for every request from a single
client (AOL in particular). Do you really want to exclude a large
proportion of the internet population?

HTH,

Mikey

attached mail follows:


Dan Trainor wrote:
> Jochem Maas wrote:
>

...

>
> I don't think that this is an issue that is specific to pr0n. Sure, the
> first thing that we think of when we hear a traded login is actually
> pr0n, but it is most definately not limited to this arena.

does anybody know whether pr0n sites have a much higher 'cheat'
percentage (regarding traded/cracked logins) than other kinds of sites..
for instance does the NewYorkTimes have major problems like this?

(I'll bet that regardless of whether NYT has these problems they are a
very expensive custom system in place to mitigate the problem!?)

>
> I appreciate the kind words mentioned by Jochem and Mikey. They see
> through the whole stereotypical "I have a username and password" thing
> and understand the true technical reasoning behind my question.

we understand the issues, we know that the topic appears regularly - and
that there are various bits of code out on the web that try to do, mostly
we are aware that its not 100% possible, and that doing it to some acceptable
level of approximation is hard... either you write it or you pay some to
write it... why? simply because only monkeys work for nothing while you rake it
in - unfortunately monkeys can't program (yet).

I think Richard Lynch already pointed that out but you didn't seem to get it.
(Also your explaination of what Open Source is showed a rather
Microsoftesque (i.e. purely economic) understanding of the concept - more's the pity)

>
> To address Mikey's question - I am not looking for a way to uniquely
> identify users. For one, it's just not possible. On top of that, the
> vast majority of members with to stay anonymous for reasons that I am
> not even going to begin to state on this list, because we all know where
> that will end up.

true enough - sad to say we live in a world where looking at the 'wrong'
picture can cost you your job/reputation - then again if you're oggling
kiddiepr0n maybe you need a visit from the authorities.

double-edged sword and all that.

then again exactly how anonymous is a creditcard transaction!

>
> I am trying to ensure that one login and one password are specific to
> one client. Several methods of this include making sure that not more
> than two IPs use a specific login/password throughout a pre-set
> threshold, and on top of this, the automatic blocking of IPs that
> attempt brute-force style attacks. These two items alone would be an
> invaluable tool in the assurance that logins and passwords are not abused.

true enough...

on a side note: maybe Dan would have been better off never mentioning his
line of business - then nobody would have been any wiser?

also you Dan, you might want to be careful how you use the word Rasmus around here

<quote>
Rasmus? Waht's he got to do with anything?
</quote>

regardless of the context you say stuff like that in, its probably not going to go
down too well on this list...
(you might get away with it if your name was Zeev, Andi, Wez, etc)

>
> Thanks again
> -dant
>

attached mail follows:


Mikey wrote:
>>To address Mikey's question - I am not looking for a way to
>>uniquely identify users. For one, it's just not possible.
>>On top of that, the vast majority of members with to stay
>>anonymous for reasons that I am not even going to begin to
>>state on this list, because we all know where that will end up.
>
>
> I think you have misunderstood me - I mean't uniquely identifying *clients*
> - browsers.
>
>
>>I am trying to ensure that one login and one password are
>>specific to one client. Several methods of this include
>>making sure that not more than two IPs use a specific
>>login/password throughout a pre-set threshold, and on top of
>>this, the automatic blocking of IPs that attempt brute-force
>>style attacks. These two items alone would be an invaluable
>>tool in the assurance that logins and passwords are not abused.
>
>
> As I say, have a look at phpsec.org - the article on sessions is what you
> want, and it will explain why doing something like that will not work as
> expected. Some proxies assign new IPs for every request from a single
> client (AOL in particular). Do you really want to exclude a large
> proportion of the internet population?
>
> HTH,
>
> Mikey
>

Mikey -

I'm pretty aware of how it all works. However, the problem lies in the
fact that because most of the pre-installed billing software relies
solely on .htaccess/.htpasswd-based authentication, it's not possible to
just change the whole login system. For the most part, they're still
using privative means of authentication which are broken to begin with.

The difficulty is trying to find a solution that would limit access and
do all the fancy stuff that we had discussed, without interfering with
the pre-existing authentication system. Many of the solutions that I've
seen so far include some mod-rewrite hackery that a PHP script or
"Gateway" modifies to allow/disallow access based on a given set of
criteria.

It's unfortunate that most of the billing systems operate this way.
They're not going to change - and I know this because I had worked with
the biggest. It would benefit them greatly to investigate other means
of authentication, perhaps with a SQL back end and such - but that is a
subject I'd not want to bring up here because I know it's been discussed
many a time on this list, and I'd hate to start another flame war.

Although it would benefit them greatly, most of their customers expect
stuff in a simplistic and uniform manner. Changing the whole
login/authentication system would wreak havoc among these clients who
are not technically inclined, and is just not possible at this time.

Friends and I have given serious thought to actually starting our own
processing solution, but it is not possible at this time due to the
large amount of liability that we would inherit. Perhaps though, with
time, this will be possible. When that time comes, we plan on having an
"open" solution that would try to set some sort of robust and highly
configurable standard for this specific application.

Thanks again for taking the time to respond.
-dant

attached mail follows:


> The difficulty is trying to find a solution that would limit
> access and do all the fancy stuff that we had discussed,
> without interfering with the pre-existing authentication
> system.

How about taking the auth status of a user from the headers and then
performing additional verification (such as IP checks - although I would
discourage that for previously mentioned reasons, or the display of a new
password for the next session and use system calls to modify the password
through htpasswd) and then storing a session var to say that the additional
auth had been passed?

Regards,

Mikry

attached mail follows:


Dan Trainor wrote:
> I'm pretty aware of how it all works. However, the problem lies in the
> fact that because most of the pre-installed billing software relies
> solely on .htaccess/.htpasswd-based authentication, it's not possible to
> just change the whole login system. For the most part, they're still
> using privative means of authentication which are broken to begin with.

I believe that you could, perhaps, consider using PHP after the existing
.htaccess/.htpasswd authentication to provide a secondary test, without
disturbing the billing software setup.

The steps involved are:

HTTP Request
.htaccess/.htpasswd Challenge/Response, drives billing software
PHP $_SERVER['HTTP_AUTH_USER']/$_SERVER['HTTP_AUTH_PW'], drives abuse check

No need for anything as fancy as an extension.

If somebody is abusing/sharing a password, they still should get billed up
to the point of account termination, right?

Whatever you would do in this extension would have to still interface to
the .htaccess/.htpasswd system to alter billable status -- Which you can
probably do far easier in PHP anyway.

PHP could generate a list of accounts that are suffering suspicious
activity, which could be provided to the billing software in whatever
manner they desire, really.

You also have the advantage that it's a LOT easier to [find somebody to]
write, test, and debug a PHP script than an extension.

You'll also be able to more easily run tests in parallel with a "live"
site but without any real action really being taken until it's all proven
and reviewed and tested thoroughly. That's gonna be a lot tougher with an
extension whose C code is burned into the Apache binary, or even as a
loadable Module of compiled C code.

You can track a variety of factors such as IP, some unchanging browser
headers, login time, page surfing, http_referrer, etc and watch for
patterns from abusive accounts.

You can't rely on IP address directly, but if the same account is given
three different IP addresses in IP-space *known* to be owned by three
different ISPs, then you've got a pretty sure bet it's an abuse.

You'll need a ton of reverse DNS or dns-by-country lookups and caching,
but it's do-able.

Analyze the hell out of a few months' worth of old data, and/or start
logging live data and look for the patterns.

Come up with a formula for an "abuse factor scorecard" and then implement
a log with PHP of what you *WOULD* do with this account, and see if you
like the results.

Change the formula, log some more, watch for awhile.

The bottom line, though, is that you *HAVE* to "interfere with the
pre-existing authentication system" at *SOME* point in order to kick users
off -- Or else always have a human review of the evidence before action.

Either way, PHP is probably a cheaper/better solution than a dedicated
module, at least unless you find out that the formula for calculating a
user's score takes *sooo* long and is so complicated that PHP can't do it
fast enough -- Even then, I'd bet the time-sink is in things like DNS data
(cache it) and in logging, not the actual calculation.

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


I've had similar problems to that.

I usually either open the image with notepad, or some Hex Editor, and
see what the bits are in the file header (eg BM for Bitmap, Gif89a for
GIFs, JFIF for JPEGs...)

--
AdamT
"Justify my text? I'm sorry, but it has no excuse."

attached mail follows:


i just opened 4 jpg files...dunno about where the header is...coz i
didn't find anything common at the begining of the files (so i doesn't
seem to have a header at the "head").

i found (only) one jpg which had JFIF as the 7th to 10th bytes.

i did notice that the _last 2 bytes_ are FF D9 in *all* 5 jpg's. that
should be a good way to check depending on how the jpeg's in question
differ from the real thing.

fopen image; fseek ( $handle, -2 , SEEK_END);
$last_2_bytes = fread ($handle, 2 [bytes]);
if ($last_2_bytes == 0xffd9), perhaps an ok jpg.

have u done anything to the images? are they photos, scanned, gaphics
(from photoshop/gimp)?

On Tue, 1 Mar 2005 09:44:08 +0000, AdamT <adwulfgmail.com> wrote:
> I've had similar problems to that.
>
> I usually either open the image with notepad, or some Hex Editor, and
> see what the bits are in the file header (eg BM for Bitmap, Gif89a for
> GIFs, JFIF for JPEGs...)

--
]#
Anirudh Dutt

...pilot of the storm who leaves no trace
like thoughts inside a dream

attached mail follows:


On Tue, 1 Mar 2005 16:06:56 +0530, anirudh dutt <aneroidgmail.com> wrote:
> i just opened 4 jpg files...dunno about where the header is...coz i
> didn't find anything common at the begining of the files (so i doesn't
> seem to have a header at the "head").
>
Okay - so 'header' was a bad choice of word. 'Marker' would have been better:

http://www.funducode.com/freec/Fileformats/format3/format3b.htm

--
AdamT
"Justify my text? I'm sorry, but it has no excuse."

attached mail follows:


On Tue, 1 Mar 2005 10:40:59 +0000, AdamT <adwulfgmail.com> wrote:
> On Tue, 1 Mar 2005 16:06:56 +0530, anirudh dutt <aneroidgmail.com> wrote:
> > i just opened 4 jpg files...dunno about where the header is...coz i
> > didn't find anything common at the begining of the files (so i doesn't
> > seem to have a header at the "head").
> >
> Okay - so 'header' was a bad choice of word. 'Marker' would have been better:

just meant i couldn't find it there.

> http://www.funducode.com/freec/Fileformats/format3/format3b.htm

very nice info on that page. thanks.

quoting...
Header :
· It occupies two bytes.
· 0xff, 0xd8 (SOI : Start Of Image ) (these two identify a
JPEG/JFIF file)

so u were right about the header bit. and as murphy would have it...i
start seeing all the JFIF stuff in the images. turns out my hex editor
scrolls to the end so i wasn't actually looking at the headers :P

got the footer right ;-)

--
]#
Anirudh Dutt

...pilot of the storm who leaves no trace
like thoughts inside a dream

attached mail follows:


When I install PHP 4.3.10 with Apache 2.0 with a tool called YUM that
installs rpms for Fedora Core 3 I get the following:

Apache is running a threaded MPM, but your PHP Module is not compiled to be
threadsafe. You need to recompile PHP. Pre-configuration failed

I¹m not sure why Fedora would distribute a package that wouldn¹t work with
other packages, however what is this Œthreadsafe¹ feature and how can I
specifically enable it so I can get php installed?

Thanks!
T

attached mail follows:


dear friends,
can u help me to find the current directory where my php files are..
using php.
thanks,
karthik

attached mail follows:


K Karthik wrote:
> dear friends,
> can u help me to find the current directory where my php files are..
> using php.

echo dirname($_SERVER['PHP_SELF']);

Please, read the manual and search the archives.

attached mail follows:


> On Thu, 24 Feb 2005 10:54:02 +0100, Gerard <Fahrlycantrope.com> wrote:
> >
> > Nevertheless, it IS slow and I have no idea why or where to
> start looking.
> > The phpinfo() can be found on www.debuginc.com/info.php. Any
> help or hints
> > are highly appreciated.
>
> It looks like you are using Debian and probably did an apt-get install
> php. Why don't you try compiling php by hand without all the extra
> crap that I'm sure you don't need then try it. I think you will be
> much happier. Debian is great software, but when it comes to things
> like web services and php it is much better to compile by hand to get
> the best performance.
>
Thanks for that one! After a manual compile it all works fine :D

- Gerard

attached mail follows:


overbored wrote:

>>
>>>Hi all, I'm learning PHP and I'd need to create a simple Web-based
>>>ifconfig tool for a Soekris box (running Pebble). However, I've been
>>>unsuccessful at getting PHP working with mini_httpd. In particular,
>>>the POST data is not being received. Here's what I did...
>>
>>What version of PHP are you running? $_POST and other $_* variable are
>>only available in PHP versions 4.2.+ iirc.
> $ php --version
> PHP 4.3.10-2 (cli) (built: Dec 19 2004 03:41:45)
> Copyright (c) 1997-2004 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

This is the client build, which might not be the same as your server
build. Run phpinfo() and check your version there.

attached mail follows:


Thanks, Dan. I copied your code exactly and posted it here:
http://www.tidefans.com/test.php I pasted a large part of O'Henry's "Gift of
the Magi" into the textarea, and it gets repeated, as before.

Thanks for any help,
Elizabeth

-----Original Message-----
From: Dan Tappin [mailto:danorourke.ca]
Sent: Monday, February 28, 2005 6:59 PM
To: Elizabeth Lawrence
Subject: Re: [PHP] textarea posting duplicate text

Create a new file:

test.php

with this exactly in the contents:

<HTML>
        <HEAD>
                <TITLE>TEST</TITLE>
        </HEAD>

        <BODY>
                <FORM ACTION="test.php" METHOD="post" NAME="test">
                        <TEXTAREA NAME="textarea" ROWS="4"
COLS="40"></TEXTAREA>
                        <P><INPUT TYPE="submit" NAME="submitButtonName"></P>
                </FORM>
                <P><? print_r($_REQUEST); ?></P>
        </BODY>

</HTML>

Load the page, enter some text and hit submit. Rule out some strange
issue with your page. Confirm it's a PHP issue not a coding one.

Dan T

On Feb 28, 2005, at 8:03 AM, Elizabeth Lawrence wrote:

> Hello. I have been asked to look at a PHP issue for someone, and I
> can't
> figure out what the problem is. I'm hoping one of you experts can help!
>
>
>
> They are using Red Hat Linux / Ensim Pro 4.0.2, PHP 4.3.10, and Apache
> 2.0.
>
>
>
> The problem: When a lot of text is entered into a textarea on a form,
> the
> text that shows up in the $_POST['textarea'] variable has the text
> that was
> entered, but it is duplicated. This is causing problems for their
> forums.
> Here is a very simple script I placed on the server:
> www.tidefans.com/textarea_test.php (code below)
>
> When I place the same script on another server I have access to, the
> textarea text is "posted" fine.
>
> Is this a PHP setting somewhere that I'm missing?
>
>
>
> Here is the code for the PHP script mentioned above:
>
> <html>
>
> <head>
>
> <title>Test PHP Script</title>
>
> </head>
>
> <body>
>
> <form method=post action="textarea_test.php" name="Form1">
>
> <textarea cols=50 rows=20 name=textarea>
>
> //[a bunch of text goes here]
>
> </textarea><br>
>
> <input type=text name=text size=20 value="This is some text"><br>
>
> <input type=submit name=Submit value="Submit">
>
> <?php
>
> if ($_POST[Submit] != "")
>
> {
>
> echo "<h1>_POST values</h1>";
>
> echo "<p>Textarea submitted:</p>";
>
> echo "<pre>" . $_POST[textarea] . "</pre>";
>
> echo "<p>Textbox submitted:</p>";
>
> echo "<pre>" . $_POST[text] . "</pre>";
>
> echo "<p>Submit submitted:</p>";
>
> echo "<pre>" . $_POST[Submit] . "</pre>";
>
> }
>
> ?>
>
> </form>
>
> <?php
>
> phpinfo();
>
> ?>
>
> </body>
>
> </html>
>
>
>
> If anyone can point me in the right direction, I would appreciate it so
> much!
>
> Elizabeth
>
>
>
> Elizabeth Lawrence
>
> elawrencensggroup.com
>
>
>

attached mail follows:


On Tue, 2005-03-01 at 08:43, Elizabeth Lawrence wrote:
> Thanks, Dan. I copied your code exactly and posted it here:
> http://www.tidefans.com/test.php I pasted a large part of O'Henry's "Gift of
> the Magi" into the textarea, and it gets repeated, as before.
>
> Thanks for any help,
> Elizabeth

There are some settings in php.ini that affect the max size of post
variables. It is sort of interesting to me that it is not a complete
copy but the first 1303 bytes or so are printed and then the test as a
whole is there preceded by testarea=.

It does not do this on my server. 4.3.6 apache 2

I notice that the Server API says Apache 2.0 Filter on your box and on
mine it says Apache 2.0 Handler. I have no idea what that means.

Bret

attached mail follows:


On Tue, 2005-03-01 at 10:19, Bret Hughes wrote:
> On Tue, 2005-03-01 at 08:43, Elizabeth Lawrence wrote:
> > Thanks, Dan. I copied your code exactly and posted it here:
> > http://www.tidefans.com/test.php I pasted a large part of O'Henry's "Gift of
> > the Magi" into the textarea, and it gets repeated, as before.
> >
> > Thanks for any help,
> > Elizabeth
>
>
> There are some settings in php.ini that affect the max size of post
> variables. It is sort of interesting to me that it is not a complete
> copy but the first 1303 bytes or so are printed and then the test as a
> whole is there preceded by testarea=.
>
> It does not do this on my server. 4.3.6 apache 2
>
> I notice that the Server API says Apache 2.0 Filter on your box and on
> mine it says Apache 2.0 Handler. I have no idea what that means.
>
> Bret
>

Hmm I did not remember writing the bit about post_max_size. I was
checking your settings in the phpinfo output when I found the
filter/handler deal. obviously the post_max_size is not the culprit.

Bret

attached mail follows:


It's definitely on your end:

http://www.orourke.ca/test.php

I verified your issue on your server and could not reproduce it on mine.

Our phpinfo data looks the same.

Here's a hunch. Try calling output buffering at the top of your page:

  ob_start();

I have this on my site to allow for mid-page redirects. I have no idea
if this is the cause. Just an idea. Perhaps an Apache 2 issue? Can
any one else confirm this on Apache 2 / PHP 4.3.10?

Dan T

On Mar 1, 2005, at 7:43 AM, Elizabeth Lawrence wrote:

> Thanks, Dan. I copied your code exactly and posted it here:
> http://www.tidefans.com/test.php I pasted a large part of O'Henry's
> "Gift of
> the Magi" into the textarea, and it gets repeated, as before.
>
> Thanks for any help,
> Elizabeth
>
> -----Original Message-----
> From: Dan Tappin [mailto:danorourke.ca]
> Sent: Monday, February 28, 2005 6:59 PM
> To: Elizabeth Lawrence
> Subject: Re: [PHP] textarea posting duplicate text
>
> Create a new file:
>
> test.php
>
> with this exactly in the contents:
>
> <HTML>
> <HEAD>
> <TITLE>TEST</TITLE>
> </HEAD>
>
> <BODY>
> <FORM ACTION="test.php" METHOD="post" NAME="test">
> <TEXTAREA NAME="textarea" ROWS="4"
> COLS="40"></TEXTAREA>
> <P><INPUT TYPE="submit" NAME="submitButtonName"></P>
> </FORM>
> <P><? print_r($_REQUEST); ?></P>
> </BODY>
>
> </HTML>
>
> Load the page, enter some text and hit submit. Rule out some strange
> issue with your page. Confirm it's a PHP issue not a coding one.
>
> Dan T
>
> On Feb 28, 2005, at 8:03 AM, Elizabeth Lawrence wrote:
>
>> Hello. I have been asked to look at a PHP issue for someone, and I
>> can't
>> figure out what the problem is. I'm hoping one of you experts can
>> help!
>>
>>
>>
>> They are using Red Hat Linux / Ensim Pro 4.0.2, PHP 4.3.10, and Apache
>> 2.0.
>>
>>
>>
>> The problem: When a lot of text is entered into a textarea on a form,
>> the
>> text that shows up in the $_POST['textarea'] variable has the text
>> that was
>> entered, but it is duplicated. This is causing problems for their
>> forums.
>> Here is a very simple script I placed on the server:
>> www.tidefans.com/textarea_test.php (code below)
>>
>> When I place the same script on another server I have access to, the
>> textarea text is "posted" fine.
>>
>> Is this a PHP setting somewhere that I'm missing?
>>
>>
>>
>> Here is the code for the PHP script mentioned above:
>>
>> <html>
>>
>> <head>
>>
>> <title>Test PHP Script</title>
>>
>> </head>
>>
>> <body>
>>
>> <form method=post action="textarea_test.php" name="Form1">
>>
>> <textarea cols=50 rows=20 name=textarea>
>>
>> //[a bunch of text goes here]
>>
>> </textarea><br>
>>
>> <input type=text name=text size=20 value="This is some text"><br>
>>
>> <input type=submit name=Submit value="Submit">
>>
>> <?php
>>
>> if ($_POST[Submit] != "")
>>
>> {
>>
>> echo "<h1>_POST values</h1>";
>>
>> echo "<p>Textarea submitted:</p>";
>>
>> echo "<pre>" . $_POST[textarea] . "</pre>";
>>
>> echo "<p>Textbox submitted:</p>";
>>
>> echo "<pre>" . $_POST[text] . "</pre>";
>>
>> echo "<p>Submit submitted:</p>";
>>
>> echo "<pre>" . $_POST[Submit] . "</pre>";
>>
>> }
>>
>> ?>
>>
>> </form>
>>
>> <?php
>>
>> phpinfo();
>>
>> ?>
>>
>> </body>
>>
>> </html>
>>
>>
>>
>> If anyone can point me in the right direction, I would appreciate it
>> so
>> much!
>>
>> Elizabeth
>>
>>
>>
>> Elizabeth Lawrence
>>
>> elawrencensggroup.com
>>
>>
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:


Elizabeth Lawrence wrote:
> Thanks, Dan. I copied your code exactly and posted it here:
> http://www.tidefans.com/test.php I pasted a large part of O'Henry's "Gift of
> the Magi" into the textarea, and it gets repeated, as before.

There was an Apache2/PHP bug going around that had this issue. It was an
older version of PHP and/or Apache2 that I thought was fixed, though.
Maybe your running into this same issue? Try searching the PHP bug
database for "apache2 duplicate" and see if you can find the old bug/issue.

--

---John Holmes...

Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

attached mail follows:


I agree with Mikey on the "live and let live" side of things. This forum is about sharing technical knowlege and helping other users overcome technical challenges relating to PHP.

Yeah, a site that's "adult oriented" is most likely a pay site. Doesn't mean they make money, but assuming they made boat loads of it, then yeah, they should look into paying for a solution instead of finding or conning someone into making a freebie solution. Ultimately, if they're making the kind of money that would make us have no sympathy for them, then they're making the kind of money that $350 isn't going to matter one way or another. It's not like "Muuahahahah.. we saved $350 by using free software, we're even richer now!" it's more like "Well, that's 50% off this month's hosting fees.. big deal".

But all of that deals with moral and personal issues. The meat of this discussion is "How do I make sure that someone isn't sharing their login with the world".

Here are some thoughts:

Many BitTorrent sites that monitor U/D ratios seem to use a fairly universal system that seems to involve logging into the site, your IP address is recorded in the database as belong to that account. If you log in from a different computer (which users should be able to do to some degree), it'll record THAT IP address in the database too. I don't know their criteria (probably fairly loose compared to what a pay site would want) but the issue here is more about how many CONCURRENT connections under that account are occurring.

So let's say the criteria would be "A user logs in and their IP address is recorded. They can have as many IP addresses attached to that account as they want BUT they can't have XX number of IP addresses connect within YY minutes or we consider it a pattern of login sharing."

So if you have someone who gets an account and shares it with a single friend, it probably won't trip the alarms. But really, is that such a big deal compared to someone posting their login info on a message board and 1000 people trying to use it at once?

A single person, or a person and a friend or two, aren't going to be logging in from 150 IP addresses within 5 minutes. And that's really what you're trying to prevent. The wholesale sharing of a login, not little petty sharing. So it doesn't have to be a perfect system. No need for retinal scans or anything. Just preventing large scale abuse. Which seems pretty simple to me espcially in the case of "adult oriented" sites since their logins will either be used properly (or at least reasonably) or they'll be abused to hell.

Now if you take a site like Consumer Reports or the Encyclopedia Britanica, that's a little more difficult. 1000 people aren't going to be logging in rapid-fire if it's shared. But you might get 5 or 6 a time if it's shared improperly. So you just set the threshhold a little lower. Maybe do something like block the person and make it say something like "This account is being used by too many sources at once. If this happens too many times, the password will be reset and the new password will be emailed to the legitmate owner of the account. If you received this message in error, please try back in 5 minutes. If you continue to receive this message, please contact our technical support team at XXXXYYYYY.com."

That'll discourage people from sharing since they'll get locked out of their own account. It provides incentive not to share without being too harsh about it and provides the legitmate owner a way to get in even if someone else stole and/or is abusing their account. People who are abusing or using a stolen account probably won't have access to the original account holder's email account and if the owner is sharing with some friends, they can still share but have incentive not to share TOO much.

See? None of this is impossible or even implausible and I don't see it as off topic at all. It's a good discussion with legitmate purpose, even if it is for an 'adult oriented' site.

-TG

= = = Original message = = =

[snip everything irrelevant]

On a tehnical note, I don't really see how you can prevent this sharing of
logins. This is something I was actually looking into for a site that had
nothing to do with pr0n (would love to know where that came from, it seems
so universal now).

If you read up on the general issues surrounding client identification
(http://phpsec.org) it is pretty much impossible to come up with a solution
of uniquely identifying a specific browser session that will work in all
instances. And really, this is what you are trying to get at isn't it?
Uniquely identifying your clients.

The only non-technical solution I can offer you is that you change the
passwords for each person as they login. This would make people much more
reluctant to shre their account as they would not be able to access their
own account as soon as someone else logs in with it.

Of course, people aren't gonna like have to remember all the different
passwords but I think it helps with your problem.

As for the rest of this whole thread, I think we should all be a little more
"live and let live" about this. So you don't like pr0n? So what? I know a
lot of people who do (not so much myself, am more of a doer) but I don't
think it makes them bad people. I also happen to know that not all pr0n is
about exploitation. Some is, of course, and I'm sure that even Dan would
agree that this is not good - if anyone had bothered to find out in the
first place.

I'm not trying to invite more flaming here - there have been some very valid
points made, I just hope this thread can die a quick and silent death not
that the technical issue has been addressed.

Mikey

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.

attached mail follows:


tg-phpgryffyndevelopment.com wrote:
> I agree with Mikey on the "live and let live" side of things. This forum is about sharing technical knowlege and helping other users overcome technical challenges relating to PHP.
>
> Yeah, a site that's "adult oriented" is most likely a pay site. Doesn't mean they make money, but assuming they made boat loads of it, then yeah, they should look into paying for a solution instead of finding or conning someone into making a freebie solution. Ultimately, if they're making the kind of money that would make us have no sympathy for them, then they're making the kind of money that $350 isn't going to matter one way or another. It's not like "Muuahahahah.. we saved $350 by using free software, we're even richer now!" it's more like "Well, that's 50% off this month's hosting fees.. big deal".
>

Of course I would not consider Open Source software for this purpose if
the sites themselves were making money. but the sad fact is, most of
these sites do not. Regardless, they're my customers, and they ask me
for solutions. I try my damndest to provide these solutions. Offering
the services that I provide, it would indeed be in my better interests
to make them run up a bandwidth bill, but this practice is frowned upon
by many.

> But all of that deals with moral and personal issues. The meat of this discussion is "How do I make sure that someone isn't sharing their login with the world".

I totally respect the moral and personal issues of others. However, I
do not respect those who tell me that what I am doing is *wrong*. In my
eye, they're wrong. What if I were to tell them that I didn't agree
with the child-oriented Telletubbies Web Site that they were working on?
  Do you see the logic in this? I don't.

> Here are some thoughts:
>
> Many BitTorrent sites that monitor U/D ratios seem to use a fairly universal system that seems to involve logging into the site, your IP address is recorded in the database as belong to that account. If you log in from a different computer (which users should be able to do to some degree), it'll record THAT IP address in the database too. I don't know their criteria (probably fairly loose compared to what a pay site would want) but the issue here is more about how many CONCURRENT connections under that account are occurring.
>
> So let's say the criteria would be "A user logs in and their IP address is recorded. They can have as many IP addresses attached to that account as they want BUT they can't have XX number of IP addresses connect within YY minutes or we consider it a pattern of login sharing."
>
> So if you have someone who gets an account and shares it with a single friend, it probably won't trip the alarms. But really, is that such a big deal compared to someone posting their login info on a message board and 1000 people trying to use it at once?
>
> A single person, or a person and a friend or two, aren't going to be logging in from 150 IP addresses within 5 minutes. And that's really what you're trying to prevent. The wholesale sharing of a login, not little petty sharing. So it doesn't have to be a perfect system. No need for retinal scans or anything. Just preventing large scale abuse. Which seems pretty simple to me espcially in the case of "adult oriented" sites since their logins will either be used properly (or at least reasonably) or they'll be abused to hell.
>
> Now if you take a site like Consumer Reports or the Encyclopedia Britanica, that's a little more difficult. 1000 people aren't going to be logging in rapid-fire if it's shared. But you might get 5 or 6 a time if it's shared improperly. So you just set the threshhold a little lower. Maybe do something like block the person and make it say something like "This account is being used by too many sources at once. If this happens too many times, the password will be reset and the new password will be emailed to the legitmate owner of the account. If you received this message in error, please try back in 5 minutes. If you continue to receive this message, please contact our technical support team at XXXXYYYYY.com."
>
> That'll discourage people from sharing since they'll get locked out of their own account. It provides incentive not to share without being too harsh about it and provides the legitmate owner a way to get in even if someone else stole and/or is abusing their account. People who are abusing or using a stolen account probably won't have access to the original account holder's email account and if the owner is sharing with some friends, they can still share but have incentive not to share TOO much.
>
> See? None of this is impossible or even implausible and I don't see it as off topic at all. It's a good discussion with legitmate purpose, even if it is for an 'adult oriented' site.

And again, the only reason why I am looking for ideas on this list is
because it generally promotes and comes up with some amazing ideas. I
have full faith in (most of) the users of this list, and greatly
appreciate their feedback regarding all subjects. The only thing that I
do mind is the personal attacks that I have received. I asked a
technical question to which I expected a technical answer - it was in no
way to start a flame war or to be taken out of context, even though the
underlying subject was that of adult-oriented Web Sites.
>
> -TG
>
> = = = Original message = = =
>
> [snip everything irrelevant]
>
> On a tehnical note, I don't really see how you can prevent this sharing of
> logins. This is something I was actually looking into for a site that had
> nothing to do with pr0n (would love to know where that came from, it seems
> so universal now).
>
> If you read up on the general issues surrounding client identification
> (http://phpsec.org) it is pretty much impossible to come up with a solution
> of uniquely identifying a specific browser session that will work in all
> instances. And really, this is what you are trying to get at isn't it?
> Uniquely identifying your clients.
>
> The only non-technical solution I can offer you is that you change the
> passwords for each person as they login. This would make people much more
> reluctant to shre their account as they would not be able to access their
> own account as soon as someone else logs in with it.
>
> Of course, people aren't gonna like have to remember all the different
> passwords but I think it helps with your problem.
>
> As for the rest of this whole thread, I think we should all be a little more
> "live and let live" about this. So you don't like pr0n? So what? I know a
> lot of people who do (not so much myself, am more of a doer) but I don't
> think it makes them bad people. I also happen to know that not all pr0n is
> about exploitation. Some is, of course, and I'm sure that even Dan would
> agree that this is not good - if anyone had bothered to find out in the
> first place.
>
> I'm not trying to invite more flaming here - there have been some very valid
> points made, I just hope this thread can die a quick and silent death not
> that the technical issue has been addressed.
>
> Mikey

Thanks again
-dant

attached mail follows:


On Tue, 2005-03-01 at 09:58, Dan Trainor wrote:
>
> [-- SNIIIIIIIIIIIIIIIIIIIP --]
>

Dear Dan,

You have yourself to blame for the responses you have been receiving.
You opened up the floodgates of personal opinion when you mentioned your
were a pr0n pusher. The fact that you deal with adult content was
completely irrelevant to your technical question. While I agree that
what you do is your own business, any person who finds your actions
reprehensible will more than likely find themselves morally obliged to
weigh in on their distaste.

Sincerely,
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:


Dan Trainor wrote:
<snip>
> Of course I would not consider Open Source software for this purpose if
> the sites themselves were making money. but the sad fact is, most of
> these sites do not.
</snip>

Why would you not consider OSS for a site/company that is making money?
  Open Source doesn't mean free as in beer. There's no rule stating
that you _cannot_ pay for an OS solution.

--
John C. Nichel
ÜberGeek
KegWorks.com
716.856.9675
johnkegworks.com

attached mail follows:


Robert Cummings wrote:
> On Tue, 2005-03-01 at 09:58, Dan Trainor wrote:
>
>>[-- SNIIIIIIIIIIIIIIIIIIIP --]
>>
>
>
> Dear Dan,
>
> You have yourself to blame for the responses you have been receiving.
> You opened up the floodgates of personal opinion when you mentioned your
> were a pr0n pusher. The fact that you deal with adult content was
> completely irrelevant to your technical question. While I agree that
> what you do is your own business, any person who finds your actions
> reprehensible will more than likely find themselves morally obliged to
> weigh in on their distaste.
>
> Sincerely,
> Rob.

And with that, I'd like to say that, as helpful as this list has been in
regards to the subject that I have set forth, I won't continue this
thread any longer. You guys can, but I won't.

I've obviously struck a sour cord and made many people very angry, and
although this was not my intent, I hope we can all take this as a
learning experience - to learn what kind of questions not to ask.

If anyone would like to continue this converstaion privately, I would be
more than happy to respond. However, I believe that it is in the better
interest of the majority of the members on the list to discontinue this
converstaion, and move it to a private conversation.

Jochem, and Rasmus, for that matter, should not be offended by what I
had to say. Rasmus deserves much credit for his work in regards to PHP,
but me, not being aware of who he actually was prior to all this, did
not see how he might be able to contribute *directly* to this subject.
When I asked what he has got to do with this, I believe what was
interpreted was out of context. Appologies are given where deserved,
and I'm sorry.

Thanks again all, for your replies.
-dant

attached mail follows:


Hello All,

 

I'm just beginning to experiment with encryption using the mcrypt functions
and I'm wondering if anyone can tell me if it's normal that the following
code always returns the same value whenever executed on my system (PHP
5.0.3, WinXP, mcrypt 2.5.7):

 

$td = mcrypt_module_open('rijndael-256','','cbc','');

 

srand((double) microtime() * 1000000);

 

$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),MCRYPT_RAND);

 

I was under the impression that the value in $iv should be random, whereas
on my machine it always seems to be the same value.

 

For the time being I have replaced the $iv = mcrypt_create_iv(.) etc line
with:

 

$iv = md5(uniqid(rand(), true));

 

This, at least, returns a random (random-esque?) 32 char string, but because
I don't know a great deal about encryption, I don't know if the value
returned by mcrypt_create_iv() results in stronger encryption than this or
not.

 

Can anyone help me understand why the code at top would return the same
value over and over, and also whether or not using a 32 char string
generated by "md5(uniqid(rand(), true))" is suitable to use in place of a
value returned by mcrypt_create_iv() or if there is something inherently
wrong in doing so?

 

Many thanks in advance!

 

Murray

 

attached mail follows:


Murray PlanetThoughtful wrote:
> I'm just beginning to experiment with encryption using the mcrypt
> functions
> and I'm wondering if anyone can tell me if it's normal that the following
> code always returns the same value whenever executed on my system (PHP
> 5.0.3, WinXP, mcrypt 2.5.7):
>
> $td = mcrypt_module_open('rijndael-256','','cbc','');
>
> srand((double) microtime() * 1000000);
>
> $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),MCRYPT_RAND);
>
> I was under the impression that the value in $iv should be random, whereas
> on my machine it always seems to be the same value.
>
> For the time being I have replaced the $iv = mcrypt_create_iv(.) etc line
> with:
>
> $iv = md5(uniqid(rand(), true));
>
> This, at least, returns a random (random-esque?) 32 char string, but
> because
> I don't know a great deal about encryption, I don't know if the value
> returned by mcrypt_create_iv() results in stronger encryption than this or
> not.
>
> Can anyone help me understand why the code at top would return the same
> value over and over, and also whether or not using a 32 char string
> generated by "md5(uniqid(rand(), true))" is suitable to use in place of a
> value returned by mcrypt_create_iv() or if there is something inherently
> wrong in doing so?

Can't help you with the actual question, but since you've posted it twice,
I'm assuming you've got no answers yet.

See if you can get just plain old http://php.net/rand to seem random or if
it always pops out the same numbers.

I suggest you check with the Windows list, and possibly try some
Encryption forums.

If all else fails, file it as a bug report at http://bugs.php.net/

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


Well, this time it took just 11 days to get my first bit of spam from
this mailing list.

I am most surprised that a list like this would be so open to Spiders
and other creepie crawlies. Other PHP mailing lists are fine, why can't
the original and best one be one of them ?

Alexis

attached mail follows:


Hello bob,

Tuesday, March 1, 2005, 4:11:47 PM, you wrote:

b> I am most surprised that a list like this would be so open to
b> Spiders and other creepie crawlies. Other PHP mailing lists are
b> fine, why can't the original and best one be one of them ?

I can't see how any list at all that displays the authors email
address as the From: address could ever protect you from spam of any
kind. Sure you can munge the email addresses on the archives, but you
can't stop a bot from subscribing or monitoring the usenet gateway.

Best regards,

Richard Davey
--
 http://www.launchcode.co.uk - PHP Development Services
 "I am not young enough to know everything." - Oscar Wilde

attached mail follows:


Hey Todd,

I use iframe alot.. what you have to do is tell it a target... but, i
am not sure if you can do that with header('Location:...") .. i would
be interested to know also

Joe

On Mon, 28 Feb 2005 16:30:28 -0800, Todd Cary <toddaristesoftware.com> wrote:
> My client insists on using inline Frames that uses my php pages. As an
> example, this is on one page:
>
> <IFRAME target="_top" frameborder="0"
> SRC="search.php?search_text=<?echo($search_text);?>" WIDTH=592 HEIGHT=282>
> </IFRAME>
>
> This works well with the "control" being given to search.php. What I do
> not understand is that within search.php, I have a statement that is
> suppose to pass "control" to anther page. The line is
>
> header("location: http://192.168.0.23/mypath/mypage.php");
>
> Rather than going to the page, it opens mypage.php in the inline frame.
>
> Is there a way to "leave" the inline frame?
>
> [Excuse my nomenclature e.g. "control", "leave"]
>
> Todd
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:


> > Is there a way to "leave" the inline frame?

You could get your script to write some JavaScript instead of the header
along the lines of:

window.parent.document.location = "mypage.php";

(This is not tested, and YMMV...)

HTH,

Mikey

attached mail follows:


Hey Todd... I really think what you are going to have to do is pass a
javascript variable to the parent page.. cause you are trying to send
a variable from the php search page to the parent that has the iframe
in it... I am correct in assuming that?

On Tue, 1 Mar 2005 16:33:58 -0000, Mikey <fraktotalise.co.uk> wrote:
> > > Is there a way to "leave" the inline frame?
>
> You could get your script to write some JavaScript instead of the header
> along the lines of:
>
> window.parent.document.location = "mypage.php";
>
> (This is not tested, and YMMV...)
>
> HTH,
>
> Mikey
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:


Dear phpers,
I'm using php 4.2.2 and gd version 1.8 which seems don't support gif pictures.
However, I want to send a single gif picture to the client side.
How can I do it?

Any help would be appreciated.

Sincerely,
Kun

attached mail follows:


> Dear phpers,
> I'm using php 4.2.2 and gd version 1.8 which seems don't
> support gif pictures.
> However, I want to send a single gif picture to the client side.
> How can I do it?
>
> Any help would be appreciated.

A single gif - that you have already made?

<img src="mygif.gif">

Or, if you are using a script to generate the image and are switching
between types, after you have sent the correct headers use:

readfile ("mygif.gif");

attached mail follows:


Å£À¤ wrote:
>
> Dear phpers,
> I'm using php 4.2.2 and gd version 1.8 which seems don't support gif
> pictures.
> However, I want to send a single gif picture to the client side.
> How can I do it?

Upgrade to 2.0?

Or find that third-party vendor who provided GIF support for GD 1.8 back
when GD was philosophically opposed to including it?

Since you'd have to re-install GD and then the PHP GD Module, you'd be
better off going with 2.0, almost for sure.

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


Richard Lynch wrote:
>
>
>
>
> Å£À¤ wrote:
>>
>> Dear phpers,
>> I'm using php 4.2.2 and gd version 1.8 which seems don't support gif
>> pictures.
>> However, I want to send a single gif picture to the client side.
>> How can I do it?
>
> Upgrade to 2.0?
>
> Or find that third-party vendor who provided GIF support for GD 1.8 back
> when GD was philosophically opposed to including it?
>
> Since you'd have to re-install GD and then the PHP GD Module, you'd be
> better off going with 2.0, almost for sure.

PS Just saw "mobile client" in the Subject.

I believe mobile phones use WBMP format. (Wireless Bitmap)

Which PHP/GD supports, of course. :-)

So another viable answer is: "Don't send GIF, send WBMP"

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


anirudh dutt <mailto:aneroidgmail.com>
    on Monday, February 28, 2005 9:25 PM said:

> dunno if u've read the options ppl have given u or u've ignored their
> answers:

ugh...

attached mail follows:


Position: Senior PHP Developer & MySQL DBA
Responsibilities:
   - to continue the development of a web application written in PHP and
     based on a MySQL database, application that serves a Windows client
     application
   - to manage MySQL databases and MySQL server in a Linux environment
   - to provide level 2 technical support to the Customer Care Dept. and
     sometimes to customers directly
Minimum experience: 2 years (required)
Duration: permanent
Work place: at your location
Languages:
   - English (required)
Work hours:
   - minimum 4 hours a day (required)
   - fulltime (8 hours a day) (preferred)
Qualities:
   - very serious
   - honest
   - responsible
   - dedicated and commited
Others:
   - permanent Internet connection (required)
   - permanent availability for critical situation (requires mobile a
     phone)

To apply, please send:
   - a complete resume (PDF or HTML format) (required)
   - portfolio (preferred)
   - letter of recommendations (preferred)
to rjswmw.com

attached mail follows:


Hi I have a one simple question that I need to sort out before I
continue writing any PHP scripts. Every time I call a script are the
variables reset to the default values? If for example I call action.php
from a form with a hidden value "test", I set $NUMBER to 5. If I then
call action.php again from another form with another hidden value which
means that I do not assign any number to $NUMBER, will $NUMBER now go
back to being its default value or will it stay at 5? So basically I
think my question is, each time one runs a script is it the same as
starting the application all over again? Cheers,
Rory.

attached mail follows:


Hello Rory,

Tuesday, March 1, 2005, 4:58:20 PM, you wrote:

rw> Hi I have a one simple question that I need to sort out before I
rw> continue writing any PHP scripts. Every time I call a script are the
rw> variables reset to the default values?

Yes this is nearly always the case unless you code around it.

Best regards,

Richard Davey
--
 http://www.launchcode.co.uk - PHP Development Services
 "I am not young enough to know everything." - Oscar Wilde

attached mail follows:


rory walsh wrote:
> Hi I have a one simple question that I need to sort out before I
> continue writing any PHP scripts. Every time I call a script are the
> variables reset to the default values? If for example I call action.php
> from a form with a hidden value "test", I set $NUMBER to 5. If I then
> call action.php again from another form with another hidden value which
> means that I do not assign any number to $NUMBER, will $NUMBER now go
> back to being its default value or will it stay at 5? So basically I
> think my question is, each time one runs a script is it the same as
> starting the application all over again? Cheers,
> Rory.

Every single HTTP request for a URL (every page the user clicks on, or
submits a form, or re-loads) is COMPLETELY independent of the other
requests.

The only data/values that will "survive" from script to script are the
ones you explicitly "save" and "transmit" through GET/POST/COOKIE/SESSION
mechanisms.

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


Richard Davey wrote:
> Hello Rory,
>
> Tuesday, March 1, 2005, 4:58:20 PM, you wrote:
>
> rw> Hi I have a one simple question that I need to sort out before I
> rw> continue writing any PHP scripts. Every time I call a script are the
> rw> variables reset to the default values?
>
> Yes this is nearly always the case unless you code around it.
>
> Best regards,
>
> Richard Davey

Yep. The only thing that might change would be $_SESSION variables, but
that's kind of the point of using a session. :) Or you could do
something crazy like create a specialized extension for storing state,
but almost no one does that and it certainly won't be in PHP by default.

--
Teach a man to fish...

NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-general&w=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
LAZY |
http://mycroft.mozdev.org/download.html?name=PHP&submitform=Find+search+plugins

attached mail follows:


Hi all -

I could use a lead on a problem. I just don't know where to start.

I have a PHP script that populates a database table. No big deal. It creates
mailing labels. However, a weird things keeps happening - every once in a
while, a query is run twice. It is the same query, same information, even
the same time (there is a now() in the query - and it is identical).

So the question is a simple one - is this a PHP problem or a MySQL problem?
Or somewhere in the MySQL extension? And how would I know?

There is one clue to this otherwise vague problem. I believe that this
predominantly happens when the database is under an above average load.

I would appreciate any help that I might be able to get.

Thank you.

attached mail follows:


Jed R. Brubaker wrote:
> I could use a lead on a problem. I just don't know where to start.
>
> I have a PHP script that populates a database table. No big deal. It
> creates
> mailing labels. However, a weird things keeps happening - every once in a
> while, a query is run twice. It is the same query, same information, even
> the same time (there is a now() in the query - and it is identical).
>
> So the question is a simple one - is this a PHP problem or a MySQL
> problem?
> Or somewhere in the MySQL extension? And how would I know?
>
> There is one clue to this otherwise vague problem. I believe that this
> predominantly happens when the database is under an above average load.
>
> I would appreciate any help that I might be able to get.

Possibly the users are clicking twice on "Submit" when the site is slow.

Try embedding an MD5 hash or some other random token in the FORM, and mark
them off as "used" when you INSERT a new row. If a token is "used" just
ignore the insert.

Or, better yet, check that the values are the same and ignore it, and if
they are different, because the user used their "Back" button and
submitted new data, go ahead and INSERT.

It might *NOT* be users clicking too much, but that's USUALLY the cause,
and it's easy to detect and "do the right thing" once you embed something
in each FORM to uniquely identify it before they submit it back to you.

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:


Jed R. Brubaker wrote:
> Hi all -
>
> I could use a lead on a problem. I just don't know where to start.
>
> I have a PHP script that populates a database table. No big deal. It creates
> mailing labels. However, a weird things keeps happening - every once in a
> while, a query is run twice. It is the same query, same information, even
> the same time (there is a now() in the query - and it is identical).
>
> So the question is a simple one - is this a PHP problem or a MySQL problem?
> Or somewhere in the MySQL extension? And how would I know?
>
> There is one clue to this otherwise vague problem. I believe that this
> predominantly happens when the database is under an above average load.
>
> I would appreciate any help that I might be able to get.
>
> Thank you.
>
Hi Jed

Can you post some sample code - showing how the query is called through
PHP? IMHO, at first pass it sounds like PHP rather than MySQL - but I
have been wrong before (many, many times);).

Rory

attached mail follows:


Is there some reason you can't simply use a javascript alert on the page refresh?

if(isset($queue)){
   echo "
   <script type=\"text/javascript\">
   <!--
   alert(\"$queue\");
   -->
   </script>";
}

>
> From: Lester Caine <lesterlsces.co.uk>
> Date: 2005/03/01 Tue AM 03:18:58 EST
> To: php-generallists.php.net
> Subject: Re: [PHP] Pop-up message
>
> Richard Lynch wrote:
>
> > Lester Caine wrote:
> >
> >>At the risk of being shouted at because *I* know it's not a PHP problem!
> > Actually, it's a client problem :-)
> Yep - but with so many different ways of doing it, which client method
> would be best ;)
>
> >>I have a page that is being refreshed every 30 seconds or so, and
> >>displays a list of 'tickets' waiting to be dealt with on a list from a
> >>database query. No problems there, but a couple of sites now want me to
> >>add a pop-u