php-general Digest 7 Jun 2010 09:45:48 -0000 Issue 6785
Topics (messages 305858 through 305873):
Re: unlink()?
305858 by: Ashley Sheridan
305860 by: tedd
DOMDocument throws Unexpected end tag error when loading valid HTML
305859 by: Raymond Irving
305873 by: Richard Quadling
image thumbnail from blob data
305861 by: saeed ahmed
305862 by: Ashley Sheridan
305863 by: Karl DeSaulniers
305864 by: Paul M Foster
305865 by: Phpster
305871 by: Adam Richardson
Limiting logins
305866 by: Skip Evans
305867 by: Ashley Sheridan
305868 by: Paul M Foster
305870 by: Skip Evans
DOMDocument::loadXML() failed when parsing comments inside a script tag
305869 by: Raymond Irving
305872 by: Adam Richardson
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sun, 2010-06-06 at 14:08 -0400, tedd wrote:
> At 1:02 AM +0100 6/6/10, Ashley Sheridan wrote:
> >>On Sat, 2010-06-05 at 18:55 -0400, tedd wrote:
> >>
> >>Hi gang:
> >>
> >>Never-mind.
> >>
> >>I didn't change the parent directory permissions to unlink the file -- duh!
> >>
> >>tedd
> >
> >I was just about to mention this! It's one of the bizarre security
> >loopholes in Linux. If you have write permissions to a directory but
> >not a file within it, you can still delete the file. I believe you
> >can change this behaviour with filesystem security mods, but I've
> >not tried that.
> >
> >Ash
>
> Yes, I've seen where you can delete files within a directory by
> changing the directory permissions.
>
> It's not often that my scripts create/delete files on the server --
> so I'm not up on it as much as I probably should be.
>
> However to me, it seems overly cautious to require scripts -- that
> are already running on the server -- to have the authority (ftp id
> and password) to create/delete files. After all, the scripts would
> not be there if the person who placed them there didn't have
> authority to create and delete files. So, I have to wonder under what
> scenario would evil scripts be found/run on the server?
>
> For example, if anyone was going to create an evil script and place
> it on the server, they must have the authority to do that. And if
> they had that authority, then they could just as easily add that to
> their script and side-step this requirement, right? So, what's the
> purpose?
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
I think it's more likely that a security flaw might be found which
allows code other than yours to run. Buffer overflows were notorious for
this, as they had the side-effect of running whatever ran outside of
their buffer range, so you could in effect get a system with an overflow
hole to run whatever code you wanted. Usually a problem like this would
be limited to a specific function, but if someone was able to guess
correctly that you were using this function then they could potentially
form code that exploited it.
I'm not an expert on this sort of thing, so what I've just said is how I
roughly understand one aspect of the problem.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
I think it's more likely that a security flaw might be found which
allows code other than yours to run. Buffer overflows were notorious
for this, as they had the side-effect of running whatever ran
outside of their buffer range, so you could in effect get a system
with an overflow hole to run whatever code you wanted. Usually a
problem like this would be limited to a specific function, but if
someone was able to guess correctly that you were using this
function then they could potentially form code that exploited it.
I'm not an expert on this sort of thing, so what I've just said is
how I roughly understand one aspect of the problem.
Thanks,
Ash
Ash:
Good enough.
Thanks,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Hello,
Sorry to have to be writing to you directly. I've tried sending this email
to the mailing list but it keeps returning with a failure message:
Remote host said: 550 5.7.1 reject mailfrom [sbl]
It appears that my yahoo about has been black listed?
Anyway, I'm hoping you can help me with the following issue:
I'm getting a php warning from DOMDocument after running a test script that
tried to load some html inside the DOM and then echo the html to the
browser:
Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: Unexpected end tag
: strong in Entity, line: 8 in C:\www\dom-test.php on line 23
The problem is that DOMDocument::loadHTML() attempts to remove the
'</strong>' tag from within a JavaScript string variable inside the
<script> tag. If I try to wrap <!-- --> around the content of the <script>
tag it will still throw the error.
I've tested it with php *5.2.0, 5.2.6, 5.2.11*, *5.3* and *5.3.2*. It
appears to work just fine in version 5.2.0 but the other version throw the
above error.
Here's the script. Can anyone confirm this error or is there a known
workaround?
<?php
$html = '
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<script type="text/javascript">
var html = "<strong>Bold Text</strong>,Normal Text";
document.write(html);
alert(html);
</script>
</head>
<body> </body>
</html>
';
$dom = new DOMDocument();
$dom->loadHTML($html);
echo $dom->saveHTML();
?>
Best regards
__
Raymond Irving
--- End Message ---
--- Begin Message ---
On 6 June 2010 19:56, Raymond Irving <xwis...@gmail.com> wrote:
> Hello,
>
> Sorry to have to be writing to you directly. I've tried sending this email
> to the mailing list but it keeps returning with a failure message:
>
> Remote host said: 550 5.7.1 reject mailfrom [sbl]
>
> It appears that my yahoo about has been black listed?
>
> Anyway, I'm hoping you can help me with the following issue:
>
> I'm getting a php warning from DOMDocument after running a test script that
> tried to load some html inside the DOM and then echo the html to the
> browser:
>
> Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: Unexpected end tag
> : strong in Entity, line: 8 in C:\www\dom-test.php on line 23
>
> The problem is that DOMDocument::loadHTML() attempts to remove the
> '</strong>' tag from within a JavaScript string variable inside the
> <script> tag. If I try to wrap <!-- --> around the content of the <script>
> tag it will still throw the error.
>
>
> I've tested it with php *5.2.0, 5.2.6, 5.2.11*, *5.3* and *5.3.2*. It
> appears to work just fine in version 5.2.0 but the other version throw the
> above error.
>
> Here's the script. Can anyone confirm this error or is there a known
> workaround?
>
> <?php
>
> $html = '
> <!DOCTYPE html>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
> <script type="text/javascript">
> var html = "<strong>Bold Text</strong>,Normal Text";
> document.write(html);
> alert(html);
> </script>
> </head>
> <body> </body>
> </html>
> ';
>
> $dom = new DOMDocument();
> $dom->loadHTML($html);
>
> echo $dom->saveHTML();
>
> ?>
>
>
> Best regards
> __
> Raymond Irving
>
Should the HTML be wrapped ...
<![CDATA[
<html><tag><soup>here</soup></tag></html>
]]>
?
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--- End Message ---
--- Begin Message ---
hello friends,
image store into database in a blob field, But when I'm trying to retrieve
it from the database then its cause problems.
if I'm trying header( "Content-type: image/jpeg") (if my image type is
jpeg), then its working well. but when I'm trying to mixing up this with
some HTML code then its not working. Ok I understand its not working because
the header already sent by the browser.
now suggest me what should I use there to retrieve the image from database?
I have to mix the HTML code in my script. So is their any other way to do
this without header?
saeed ahmed
http://saeed05.wordpress.com
--- End Message ---
--- Begin Message ---
On Mon, 2010-06-07 at 02:37 +0600, saeed ahmed wrote:
> hello friends,
>
> image store into database in a blob field, But when I'm trying to retrieve
> it from the database then its cause problems.
>
> if I'm trying header( "Content-type: image/jpeg") (if my image type is
> jpeg), then its working well. but when I'm trying to mixing up this with
> some HTML code then its not working. Ok I understand its not working because
> the header already sent by the browser.
>
> now suggest me what should I use there to retrieve the image from database?
> I have to mix the HTML code in my script. So is their any other way to do
> this without header?
>
> saeed ahmed
> http://saeed05.wordpress.com
Have one script that just fetches the image and sets the header for
that, and then fetch the content. I am assuming that you are storing the
images separate from the HTML in this case anyway? The only way to have
the image data inline with the HTML that I know of is to base64 encode
the image data, but that won't work on Internet Explorer (other decent
browsers work fine though)
Having said that, it's not generally a good idea to store images as
blobs in my experience. It can create slowdowns in database access, and
increases the amount of space the db requires by a lot! What most people
do I've found is to store the image as a file and store the path and
filename to it in the db. However, if the location is going to change
often then it might be best to store it as a blob like you're doing.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Sent from losPhone
On Jun 6, 2010, at 3:55 PM, Ashley Sheridan <a...@ashleysheridan.co.uk>
wrote:
On Mon, 2010-06-07 at 02:37 +0600, saeed ahmed wrote:
hello friends,
image store into database in a blob field, But when I'm trying to
retrieve
it from the database then its cause problems.
if I'm trying header( "Content-type: image/jpeg") (if my image type
is
jpeg), then its working well. but when I'm trying to mixing up this
with
some HTML code then its not working. Ok I understand its not
working because
the header already sent by the browser.
now suggest me what should I use there to retrieve the image from
database?
I have to mix the HTML code in my script. So is their any other way
to do
this without header?
saeed ahmed
http://saeed05.wordpress.com
Have one script that just fetches the image and sets the header for
that, and then fetch the content. I am assuming that you are storing
the
images separate from the HTML in this case anyway? The only way to
have
the image data inline with the HTML that I know of is to base64 encode
the image data, but that won't work on Internet Explorer (other decent
browsers work fine though)
Having said that, it's not generally a good idea to store images as
blobs in my experience. It can create slowdowns in database access,
and
increases the amount of space the db requires by a lot! What most
people
do I've found is to store the image as a file and store the path and
filename to it in the db.
+1
I would reccomend this as well. You may find blobs to be more of hogs
then blobs as things go forward. Store the link to the images in your
DB and store the images in their own folder on the server. That's been
the best way in my experience. Even with images changing out.
GL
Karl
--- End Message ---
--- Begin Message ---
On Sun, Jun 06, 2010 at 09:55:20PM +0100, Ashley Sheridan wrote:
<snip>
>
> Having said that, it's not generally a good idea to store images as
> blobs in my experience. It can create slowdowns in database access, and
> increases the amount of space the db requires by a lot! What most people
> do I've found is to store the image as a file and store the path and
> filename to it in the db. However, if the location is going to change
> often then it might be best to store it as a blob like you're doing.
>
+1
Storing blobs in an RDBMS is an abuse of the technology, IMO. RDBMSes
were not originally designed to store this type of information, and as
Ash pointed out, it still can create problems. His assessment of the
preferred method for storing this type of information is spot on. Store
them in a file and then store the file location in your database.
I don't know, but this might be use case for the new generation of NoSQL
databases. I have very little knowledge of how they store data, but I
would assume they're more accustomed to storing blobs and whole
documents. And if not, then someone should come up with one which works
this way. It would be relatively simple to create a key-locaton table
(using dbm or somesuch) and have all the actual "data" stored in files.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Jun 6, 2010, at 5:51 PM, Paul M Foster <pa...@quillandmouse.com>
wrote:
On Sun, Jun 06, 2010 at 09:55:20PM +0100, Ashley Sheridan wrote:
<snip>
Having said that, it's not generally a good idea to store images as
blobs in my experience. It can create slowdowns in database access,
and
increases the amount of space the db requires by a lot! What most
people
do I've found is to store the image as a file and store the path and
filename to it in the db. However, if the location is going to change
often then it might be best to store it as a blob like you're doing.
+1
Storing blobs in an RDBMS is an abuse of the technology, IMO. RDBMSes
were not originally designed to store this type of information, and as
Ash pointed out, it still can create problems. His assessment of the
preferred method for storing this type of information is spot on.
Store
them in a file and then store the file location in your database.
I don't know, but this might be use case for the new generation of
NoSQL
databases. I have very little knowledge of how they store data, but I
would assume they're more accustomed to storing blobs and whole
documents. And if not, then someone should come up with one which
works
this way. It would be relatively simple to create a key-locaton table
(using dbm or somesuch) and have all the actual "data" stored in
files.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
In my experience, most RDBMs fail at blobs and internally they still
store it as a file with a pointer. It's also worthwhile noting that in
all cases, after a certain size in the db is reached, performance is
impacted. With mysql, it seems to be about 12gb and with SQL server
it's around the 15gb size.
I had to write a script that would pull those images and store them on
the file system and when run, it reduced the size of the db to about 1
gb in all instances, if not smaller. This dramatic change reduces back
up time and costs, making the clients way happier since the performace
also picked up.
As mentioned, it's just not worth storing in the db.
Bastien
Sent from my iPod
--- End Message ---
--- Begin Message ---
On Sun, Jun 6, 2010 at 8:24 PM, Phpster <phps...@gmail.com> wrote:
>
>
> On Jun 6, 2010, at 5:51 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
>
> On Sun, Jun 06, 2010 at 09:55:20PM +0100, Ashley Sheridan wrote:
>>
>> <snip>
>>
>>
>>> Having said that, it's not generally a good idea to store images as
>>> blobs in my experience. It can create slowdowns in database access, and
>>> increases the amount of space the db requires by a lot! What most people
>>> do I've found is to store the image as a file and store the path and
>>> filename to it in the db. However, if the location is going to change
>>> often then it might be best to store it as a blob like you're doing.
>>>
>>>
>> +1
>>
>> Storing blobs in an RDBMS is an abuse of the technology, IMO. RDBMSes
>> were not originally designed to store this type of information, and as
>> Ash pointed out, it still can create problems. His assessment of the
>> preferred method for storing this type of information is spot on. Store
>> them in a file and then store the file location in your database.
>>
>> I don't know, but this might be use case for the new generation of NoSQL
>> databases. I have very little knowledge of how they store data, but I
>> would assume they're more accustomed to storing blobs and whole
>> documents. And if not, then someone should come up with one which works
>> this way. It would be relatively simple to create a key-locaton table
>> (using dbm or somesuch) and have all the actual "data" stored in files.
>>
>> Paul
>>
>> --
>> Paul M. Foster
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> In my experience, most RDBMs fail at blobs and internally they still store
> it as a file with a pointer. It's also worthwhile noting that in all cases,
> after a certain size in the db is reached, performance is impacted. With
> mysql, it seems to be about 12gb and with SQL server it's around the 15gb
> size.
>
> I had to write a script that would pull those images and store them on the
> file system and when run, it reduced the size of the db to about 1 gb in all
> instances, if not smaller. This dramatic change reduces back up time and
> costs, making the clients way happier since the performace also picked up.
>
> As mentioned, it's just not worth storing in the db.
>
> Bastien
>
> Sent from my iPod
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi all,
Indeed, I believe that the balance typically shifts in favor of storing meta
information about the image in the database, leaving the web server to
handle storing the actual image. However, I've also worked on apps where
the balance appeared to shift towards storing the image in the DB.
For example, we were running ASP.Net, had 1 load balancer, 3 web servers,
and 1 super-duper DB server (the site is subject to very large spikes, and
generally high traffic.) The client used my custom CMS to administer
content, including images (not for the site templates, but rather for the
items they were specifically managing on their site.)
I could have chosen to store the images on one of the web servers, but that
posed issues in terms of maintenance and also the webservers were not as
reliable as the DB (per SLA and the equipment used, as the DB server had
internal redundancies built-in, and those who've worked with IIS are likely
familiar with the "It's not working, let's just reboot" methodology for
servers.) I could have duplicated the images across all of the servers.
However, keeping things synched, when coupled with the security
requirements, proved to add a fair amount of complexity (not that it was
impossible, but troublesome given the budget, timeline, and the fact I
wasn't the sa.) I could have set up another server as a media server, but
that wasn't logistically feasible at the time (there are other options I've
not mentioned, too.)
I decided to examine the performance of an architecture where we stored the
images in the DB, as this app was unique in a few ways. First, each image
was limited to less-than 45KB (pretty small.) Second, the DB is relatively
small, containing thousands of items that they manage (old records are
frequently purged.) After running several benchmarks, I realized that the
website performed very well using this architecture (although I found
several other issues in terms of performance, not that they were because of
my [cough] code ;)
I sometimes hear people lament the speed of PHP. As Rasmus Lerdorf points
out in his presentation "Simple is Hard" (
http://talks.php.net/show/froscon08), PHP is rarely the bottleneck. When I
ask those who take issue with PHP's speed what they're basing it on, I find
few back it up with meaningful numbers, or if they do, they're pointing to
the comparison of PHP to some other language while running a for loop, which
is interesting if you're writing a for-looper app. Rarely have these
naysayers benchmarked PHP in the greater ecosystem of an application (and
rarely have they come to grips with the technological grandeur of what
flickr and facebook accomplish every second) to realize that it's not the
bottleneck.
All this to say, there are ideas and schemes that generally prove true, and
I believe that it is generally a better approach to avoid storing images in
a DB. However, I hope we still take the opportunity to make sure the
numbers back up the generalized approach in the specific case at hand, and
we're addressing the true bottlenecks in our application. I wouldn't have
pursued the architecture above under normal circumstances, but the
constraints forced me to try something new, and contrary to me expectations,
performance was no issue at all.
Morals of the story:
Huge bottlenecks can hide in tiny bits.
Don't judge a bottleneck by it's cover(-age online ;)
It ain't a bottleneck until it's a bottleneck.
[OK, OK, I'll stop!]
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
Hey all,
I'm familiar with setting cookies in PHP and using REMOTE_ADDR
to get a visitor's IP address (or that of their gateway), but
not quite sure how to implement a robust mechanism that would
limit a user to logging in from only two different machines, a
requirement this client has on the project.
I'd greatly appreciate hearing from people who have done this
or something similar, or suggestions people might have that
would give that oh so familiar, "D'oh!" moment.
I have some ideas sketched out, setting cookies, etc, but not
sure how robust they'd be.
Big Thanks!
Skip
--
====================================
Skip Evans
PenguinSites.com, LLC
503 S Baldwin St, #1
Madison WI 53703
608.250.2720
http://penguinsites.com
------------------------------------
Those of you who believe in
telekinesis, raise my hand.
-- Kurt Vonnegut
--- End Message ---
--- Begin Message ---
On Sun, 2010-06-06 at 20:31 -0500, Skip Evans wrote:
> Hey all,
>
> I'm familiar with setting cookies in PHP and using REMOTE_ADDR
> to get a visitor's IP address (or that of their gateway), but
> not quite sure how to implement a robust mechanism that would
> limit a user to logging in from only two different machines, a
> requirement this client has on the project.
>
> I'd greatly appreciate hearing from people who have done this
> or something similar, or suggestions people might have that
> would give that oh so familiar, "D'oh!" moment.
>
> I have some ideas sketched out, setting cookies, etc, but not
> sure how robust they'd be.
>
> Big Thanks!
> Skip
>
> --
> ====================================
> Skip Evans
> PenguinSites.com, LLC
> 503 S Baldwin St, #1
> Madison WI 53703
> 608.250.2720
> http://penguinsites.com
> ------------------------------------
> Those of you who believe in
> telekinesis, raise my hand.
> -- Kurt Vonnegut
>
Is this two machines at the same time, or two machines ever?
I don't think there's any way you can guarantee either, unless you
supply them with some form of closed binary that they are forced to use
either instead of or with the browser, i.e. a Java applet, etc.
A similar question to this came up on the list not so long ago, and
there was no real conclusion at the end other than it can't really be
done. Cookies can be deleted, IP addresses change all the time (either
deliberately, by some proxy or even by the ISP itself issuing a dynamic
IP address), even the MAC address (if you found a way to get at it) can
change.
About the only thing I've seen that might help was a device made for the
Bloomberg stock market system, which was a small credit-card sized
object which would read in a random pattern of flashes from the screen
and produce a unique ID number which was then keyed back into the
system. By relying on a physical dongle you can pretty much guarantee
that a user is only on one system, but the project obviously becomes
much more costly and complicated.
If you do go the cookie route, maybe gather a bunch of information to
store on the server against that cookie and the user. If the cookie is
not detected the next time the user goes to log in, maybe force them to
send an email requiring a manual unlock, and make them give a reason for
either why the cookie was removed, or why the computer information has
changed beyond the two computer profiles you've got stored for them.
It's not foolproof, but might show your client why this isn't something
that can be easily done, and is not something that should be decided on
lightly, as there are many valid and genuine reasons why somebody might
want to use more than two computers (i.e. they had a fire and lost those
computers, they rebuilt a computer with a new OS, they upgraded the
computer, a computer was stolen and needed to be replaced, they are away
from their computer and had to use a public access one, etc. The list
can go on and on.)
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Sun, Jun 06, 2010 at 08:31:22PM -0500, Skip Evans wrote:
> Hey all,
>
> I'm familiar with setting cookies in PHP and using REMOTE_ADDR
> to get a visitor's IP address (or that of their gateway), but
> not quite sure how to implement a robust mechanism that would
> limit a user to logging in from only two different machines, a
> requirement this client has on the project.
>
> I'd greatly appreciate hearing from people who have done this
> or something similar, or suggestions people might have that
> would give that oh so familiar, "D'oh!" moment.
>
> I have some ideas sketched out, setting cookies, etc, but not
> sure how robust they'd be.
As Ash said, this has been discussed recently on the list. Mostly the
answer was, "Yes, but you could hack that system...."
How much that matters depends on what you're protecting. Obviously, you
have to ask the user for a username and password. Hash the password and
compare it to the hash stored when the user originally registered. When
logging in, the login routine should also store an IP and browser ID.
Store this information in a cookie, and recall it when the user tries to
access another page on the site. (Don't store the password in the
cookie.) If the user ID, IP and browser ID don't match, make them login
again. And of course, set a time limit on the cookie.
Yes, you can hack the IP. Yes, you can hack the browser ID. So again, it
depends on what you're trying to allow access to. But a system such as
the above should suffice for most applications. If your needs are so
stringent that such a system wouldn't work, you may find yourself asking
extra security questions at login, storing a random hash in the database
and in a cookie (with a time limit on it), logging all access attempts,
and comparing the hash in the database with the cookie hash at each page
access. Perhaps even generating a new hash at each page access. And even
then....
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Hey Ash & all,
Thanks for that detailed explanation.
This is a lot of what I was thinking. Cookies can get deleted,
etc, and all the other things that can toss wrenches into this.
To clarify, they want to limit a single user to two machines
max, but only one at a time.
I'm going to have to explain to them the problems with this
and see what else they can work out.
The manual unlock Ash suggests is interesting, and I'll run
that by them, but I'm thinking they might opt to forgo the
limit for now to avoid risking pissing off new customers with
something that might be more of a hassles for them than it's
worth.
Thanks much for your input. This is a lot of good stuff to
help me articulate a response to the client.
Skip
Ashley Sheridan wrote:
On Sun, 2010-06-06 at 20:31 -0500, Skip Evans wrote:
Hey all,
I'm familiar with setting cookies in PHP and using REMOTE_ADDR
to get a visitor's IP address (or that of their gateway), but
not quite sure how to implement a robust mechanism that would
limit a user to logging in from only two different machines, a
requirement this client has on the project.
I'd greatly appreciate hearing from people who have done this
or something similar, or suggestions people might have that
would give that oh so familiar, "D'oh!" moment.
I have some ideas sketched out, setting cookies, etc, but not
sure how robust they'd be.
Big Thanks!
Skip
--
====================================
Skip Evans
PenguinSites.com, LLC
503 S Baldwin St, #1
Madison WI 53703
608.250.2720
http://penguinsites.com
------------------------------------
Those of you who believe in
telekinesis, raise my hand.
-- Kurt Vonnegut
Is this two machines at the same time, or two machines ever?
I don't think there's any way you can guarantee either, unless you
supply them with some form of closed binary that they are forced to use
either instead of or with the browser, i.e. a Java applet, etc.
A similar question to this came up on the list not so long ago, and
there was no real conclusion at the end other than it can't really be
done. Cookies can be deleted, IP addresses change all the time (either
deliberately, by some proxy or even by the ISP itself issuing a dynamic
IP address), even the MAC address (if you found a way to get at it) can
change.
About the only thing I've seen that might help was a device made for the
Bloomberg stock market system, which was a small credit-card sized
object which would read in a random pattern of flashes from the screen
and produce a unique ID number which was then keyed back into the
system. By relying on a physical dongle you can pretty much guarantee
that a user is only on one system, but the project obviously becomes
much more costly and complicated.
If you do go the cookie route, maybe gather a bunch of information to
store on the server against that cookie and the user. If the cookie is
not detected the next time the user goes to log in, maybe force them to
send an email requiring a manual unlock, and make them give a reason for
either why the cookie was removed, or why the computer information has
changed beyond the two computer profiles you've got stored for them.
It's not foolproof, but might show your client why this isn't something
that can be easily done, and is not something that should be decided on
lightly, as there are many valid and genuine reasons why somebody might
want to use more than two computers (i.e. they had a fire and lost those
computers, they rebuilt a computer with a new OS, they upgraded the
computer, a computer was stolen and needed to be replaced, they are away
from their computer and had to use a public access one, etc. The list
can go on and on.)
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
====================================
Skip Evans
PenguinSites.com, LLC
503 S Baldwin St, #1
Madison WI 53703
608.250.2720
http://penguinsites.com
------------------------------------
Those of you who believe in
telekinesis, raise my hand.
-- Kurt Vonnegut
--- End Message ---
--- Begin Message ---
Hello,
I'm experiencing another issue when attempting to use DOMDocument::loadXML()
to load the following HTML code:
<?php
$html = '
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html>
<body>
<script type="text/javascript">
<!--
var i = 0, html = "<strong>Bold Text</strong>,Normal Text";
document.write(html);
i--; // this line causes the parser to fail
alert(html);
-->
</script>
</body>
</html>';
$dom = new DOMDocument();
$dom->loadXML($html);
echo $dom->saveHTML();
?>
The parser throws the following error when it encounters "i--" in inside the
<script> tag:
Warning: DOMDocument::loadXML() [domdocument.loadxml]: Comment not
terminated <!-- var i = 0, html = "<strong>Bold Text< in Entity
If I remove the like "i--" it will load the HTML code just fine.
Any ideas as to why this throws an error?
__
Raymond
--- End Message ---
--- Begin Message ---
On Sun, Jun 6, 2010 at 10:39 PM, Raymond Irving <xwis...@gmail.com> wrote:
> Hello,
>
> I'm experiencing another issue when attempting to use
> DOMDocument::loadXML()
> to load the following HTML code:
>
> <?php
> $html = '
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> <html>
> <body>
> <script type="text/javascript">
> <!--
> var i = 0, html = "<strong>Bold Text</strong>,Normal Text";
> document.write(html);
> i--; // this line causes the parser to fail
> alert(html);
> -->
> </script>
> </body>
> </html>';
> $dom = new DOMDocument();
> $dom->loadXML($html);
> echo $dom->saveHTML();
> ?>
>
> The parser throws the following error when it encounters "i--" in inside
> the
> <script> tag:
>
> Warning: DOMDocument::loadXML() [domdocument.loadxml]: Comment not
> terminated <!-- var i = 0, html = "<strong>Bold Text< in Entity
>
> If I remove the like "i--" it will load the HTML code just fine.
>
> Any ideas as to why this throws an error?
>
> __
> Raymond
>
A comment declaration starts with "<!", and ends with ">", with any number
of comments following the form --comment-- in between:
http://htmlhelp.com/reference/wilbur/misc/comment.html
You'll see at the bottom of the article that they advocate a simple rule in
comments:
An HTML comment begins with "<!--", ends with "-->" and does not contain "--"
or ">" anywhere in the comment.
The occurrence of "i--" breaks that rule.
In your case, if you're maintaining the pages, you can place the javascript
in a separate file or place the javascript in a CDATA section. If you're
parsing pages you don't maintain, you can rip out the javascript before
performing DOM tasks and parse it separately as needed to avoid potential
issues.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
