|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: php-general-digest-help
lists.php.netDate: Sun Jul 07 2002 - 00:18:19 CDT
php-general Digest 7 Jul 2002 05:18:19 -0000 Issue 1449
Topics (messages 105872 through 105923):
Re: phpBB Info
105872 by: Stuart Dallas
105890 by: Richard Lynch
Re: PHP 4 broken after Apache upgrade
105873 by: Chris Garaffa
Re: [PHP-GTK] Cannot enable extensions. Why?
105874 by: George Hester
FTP commands
105875 by: Jose Arce
105891 by: Richard Lynch
105910 by: Jose Arce
Re: Compiling PHP
105876 by: Chris Hewitt
Re: How to cast objects in arrays.
105877 by: Anas Mughal
Help w/ sessionl variables plz!
105878 by: Anthony Rodriguez
105892 by: Richard Lynch
Re: Uninitialized string offset
105879 by: Uri Even-Chen
Re: suppressing errors with ""
105880 by: Uri Even-Chen
Help needed with hexdec();
105881 by: frank.hertogs.info
105893 by: Richard Lynch
Re: HTTPS vs. HTTP ?
105882 by: Richard Lynch
105884 by: Richard Lynch
105886 by: Richard Lynch
105901 by: Chris Shiflett
105907 by: Alberto Serra
105909 by: Richard Lynch
105913 by: Chris Shiflett
105917 by: Chris Shiflett
Re: upload file size
105883 by: Richard Lynch
Re: Stored Procedures
105885 by: Richard Lynch
105898 by: James Drabb
Re: mail help, and php.ini help.
105887 by: Richard Lynch
Re: help help help!!!!!!pls........
105888 by: Richard Lynch
Re: Figuring Out the Best Day in stats program
105889 by: Richard Lynch
105905 by: JJ Harrison
iptables logging
105894 by: James Drabb
105896 by: James Drabb
PHP/MySQL and parameterized queries
105895 by: Henry
Error: Parse error: parse error, unexpected $ in...
105897 by: Shiloh Madsen
105899 by: Jose Arce
issue with script after php upgrade
105900 by: Jamie Novak
105902 by: Jason Wong
105904 by: Jamie Novak
105906 by: Alberto Serra
Re: I would like to ask about Photo Upload in mysql and reteive problem .
105903 by: Jason Wong
Retrieving/Displaying hyperlinked images with PHP
105908 by: markbm
Re: Thanks
105911 by: Alberto Serra
105915 by: B.C. Lance
105918 by: Alberto Serra
105919 by: B.C. Lance
105920 by: Alberto Serra
105921 by: B.C. Lance
Posting with refresh META
105912 by: Alberto Serra
Re: HTTPS vs. HTTP ? - the weakest link
105914 by: B.C. Lance
ðÒÉ×ÅÔ!
105916 by: Alberto Serra
Having more problems
105922 by: Shiloh Madsen
Re: Thanks -> Actually POSTING without javascript
105923 by: Alberto Serra
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:
On Saturday, July 6, 2002 at 5:35:26 PM, "BrettM" wrote:
> I wanna be able to do some stuff, which involves getting data from my phpBB
> board.
> Member Count: (this section should autoupdate)
> Number Of Forums: (this section should autoupdate)
> Highest Post Count: (this section shouldauto update((member) with (post
> count) posts))
> Most Replied to topic: (this section should auto update((topic) with (number
> of replys) replys))
> Can someone give me the code to do this
> the page with this on is in my base directory. My forums are in /forums
This is not a place where you can get free development. It is here to provide
help to PHP developers. If you need some development done then there are plenty
of people/places that can assist you.
If I have misunderstood your post and you have tried to do this yourself but
are having problems, please post more information such as your source code
along with a full description of the problem(s) you're having including any
error messages.
-- Stuart
attached mail follows:
>I wanna be able to do some stuff, which involves getting data from my phpBB >board. > >Member Count: (this section should autoupdate)
select count(*) from some_table_whose_name_I_do_not_know_but_you_can_look_up_in_phpMyAdmin
>Number Of Forums: (this section should autoupdate)
select count(*) from some_table_whose_name_I_do_not_know_but_you_can_look_up_in_phpMyAdmin
>Highest Post Count: (this section shouldauto update((member) with (post >count) posts))
select member.name, count(*) as score from members, posts where posts.member_id = members.member_id group by posts.member_id, member_name order by score desc limit 1
>Most Replied to topic: (this section should auto update((topic) with (number >of replys) replys))
This one I'd have to actually look at the phpBB schema to see how they did their threading...
You'd have to pay me for this answer. Sorry.
I'm willing to bet that if you do the first three for yourself, you can do this last one with a minimal amount of effort.
Honestly, though, you really sound like that kid in school who walked in without even trying to do his homework and said it was "too hard".
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
That's exactly what I needed to do... Thanks Devrim and Chris for your quick help. AhhhŠ back to coding!
-- Chris Garaffa #!/usr/local/lib/php $contact_info["Name"] = "Chris Garaffa"; $contact_info["Email"] = "aquaxHe who calles himself "Devrim GUNDUZ" (from <devrim
attached mail follows:
All fixed. Install the new PHP using the installer to get mappings set (almost) correctly in IIS 5. Make sure PHP works now. Then rename C:\php to C:\php01. Download the 5MB package with the components. Then rename the directory that conatins the files to php and put in C drive. Leave the ini alone that the installer put in and that may have been customized. Make sure everything still works. Trash C:\php01. Done. Components will now work. This issue resulted from the versions of php.exe in the installer and in the 5MB being different although both are called version 4.2.1. Thanks everyone. Steph and Jason.
-- George Hester _________________________________ "Steph" <sfox
attached mail follows:
Hi, i'm making a script, that logs some ftp characteristics, like resume support and stuff...i try using ftp_site(), but it's not working
I want to send a command like REST, but ftp_site() send the command like this: SITE REST, with the SITE before the command...any way to do it? Thx :D
_________________________________________________________________ Únase al mayor servicio mundial de correo electrónico: http://www.hotmail.com/es
attached mail follows:
> >Hi, i'm making a script, that logs some ftp characteristics, like resume >support and stuff...i try using ftp_site(), but it's not working > >I want to send a command like REST, but ftp_site() send the command like >this: SITE REST, with the SITE before the command...any way to do it? >Thx :D
This is just a Wild Guess, since I haven't read the manual (did you?) but I'm guessing that ftp_site() sends a command with "SITE" before it, but you can use other functions to open up an FTP connection and send any old command you like...
Just a guess, though. I'd have to actually read the manual *for* you to answer this one, and I'm not willing to do that.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>From: "Richard Lynch" <richphpbootcamp.com>
>To: php-generallists.php.net
>Subject: [PHP] Re: FTP commands
>Date: Sat, 06 Jul 2002 17:02:20 -0500
>
> >
> >Hi, i'm making a script, that logs some ftp characteristics, like resume
> >support and stuff...i try using ftp_site(), but it's not working
> >
> >I want to send a command like REST, but ftp_site() send the command like
> >this: SITE REST, with the SITE before the command...any way to do it?
> >Thx :D
>
>This is just a Wild Guess, since I haven't read the manual (did you?) but
>I'm guessing that ftp_site() sends a command with "SITE" before it, but you
>can use other functions to open up an FTP connection and send any old
>command you like...
>
>Just a guess, though. I'd have to actually read the manual *for* you to
>answer this one, and I'm not willing to do that.
>
>http://php.net/ftp
>
>--
>Like Music? http://l-i-e.com/artists.htm
>
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
_________________________________________________________________ Únase al mayor servicio mundial de correo electrónico: http://www.hotmail.com/es
attached mail follows:
Leon,
This was discussed on this list at length, ending about a week or so ago. Please look in the archives for it. There was a lot of detail which may be useful to you. Basically the consenus answer was no.
Regards
Chris
Leon Mergen wrote:
>Hello, > >I'm currently camping with a problem... I have written a PHP application for >a client of mine, however, I do not want have him seeing the source code. I >know Zend has the Zend Encoder, however, this piece of software costs $2400 >
attached mail follows:
Thanks to everyone!!!
I have figured it out...
Anas Mughal <anasmughalyahoo.com> wrote: I have a function getRow() that returns a new instance
of an object called IvActivity. I insert this new
instance into $list. I need to call getTitle method on
each of the inserted objects. However, I keep on
getting parse error on the line that does the casting.
Please help.
$i = 0; while ($row = mysql_fetch_array($mysql_result)) { $instance = $this->getRow($row); $list[$i] = $intance; $i++; }
// ...
foreach ($list as $item) { $act = (IvActivity) $item; echo "item: " . $act->getTitle(); }
(I also tried simple for loop with $list[$i] logic. Unf, I am not able to cast those objects either.)
__________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
--------------------------------- Do You Yahoo!? New! SBC Yahoo! Dial - 1st Month Free & unlimited access
attached mail follows:
The following PHP script doesn't pass $course ("statistics") to the next script. Why?
<?php // file: "root/reg_users_2.php", updated: 07/06/02 set_time_limit(300); session_start(); session_register("course"); $course="statistics"; header ("location:estadisticas/contents.php"); flush(); exit; ?>
Thanks!
Tony
attached mail follows:
>The following PHP script doesn't pass $course ("statistics") to the next >script. Why? > ><?php >// file: "root/reg_users_2.php", updated: 07/06/02 >set_time_limit(300); >session_start(); >session_register("course"); >$course="statistics"; >header ("location:estadisticas/contents.php"); >flush(); >exit; >?>
Three problems.
1. You are missing a space after the : in your header("Location: ..."); 2. Location should be capitalized. 3. You are sending Cookie headers (session_start) and Location header in the same script, and that just won't work.
Don't do the Location. Use a META tag, or re-design your application to just give them the contents they want right there, not go off to some other page to give them the contents.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
Thanks for the advice! I understand the problem now. I think they added
the Uninitialized
string offset in Version 4.1.0 (see
<http://www.php.net/ChangeLog-4.php>). That's why I didn't get this
warning before. Anyway, I think I'll just add a "" sign to suppress
warnings. I tried it last nights and it works.
Uri. --------------------------------------------------------
Richard Lynch wrote: > > >After upgrading to Red Hat Linux 7.3 (which also includes a new PHP > >version), I saw this warning (Uninitialized string offset) on my apache > >error log files. It refers to a line which was perfectly legal before: > > The new settings in php.ini are error_reporting E_ALL by default. > > Those errors have always been there, have always been generated, and you've > been "ignoring" them. > > > if > >(isset($GLOBALS['SPEEDY_GLOBAL_VARS']['CURRENT_USER']['UserName'])) > > > >I always use isset to check if a variable is defined. Do you know why I > >get this warning? > > Best Guess: > > PHP is only checking if the *LAST* array reference "isset" -- and to do > that, *has* to assume that the others are there -- IE, that > $GLOBALS['SPEEDY_GLOBAL_VARS']['CURRENT_USER'] is set... > > Change it to this: > > if (isset($GLOBALS['SPEEDY_GLOBAL_VARS'] && > $GLOBALS['SPEEDY_GLOBAL_VARS']['CURRENT_USER'] && > $GLOBALS['SPEEDY_GLOBAL_VARS']['CURRENT_USER']['UserName']){ > > -- > Like Music? http://l-i-e.com/artists.htm
--------------------------------------------------------
attached mail follows:
Thanks! I also think it might be a bug. I reported it as a bug report.
Uri. --------------------------------------------------------
Miguel Cruz wrote:
>
> On Sat, 6 Jul 2002, Uri Even-Chen wrote:
> > I tried to suppress warnings in isset expressions (Uninitialized string
> > offset warnings). The original line was something like this:
> >
> > if (!(isset($GLOBALS['SPEEDY_GLOBAL_VARS']['PAGE_NAME'])))
> >
> > When I added the "" sign like this:
> >
> > if (!(isset($GLOBALS['SPEEDY_GLOBAL_VARS']['PAGE_NAME'])))
> >
> > My program stopped working, and I got errors like:
> >
> > PHP Parse error: parse error, expecting `T_VARIABLE' or `'$'' ....
> >
> > Eventually, I put the "" in this place:
> >
> > if (!(isset($GLOBALS['SPEEDY_GLOBAL_VARS']['PAGE_NAME'])))
> >
> > Which works, but why didn't it work the other way? Is it some kind of
> > PHP bug?
>
> It does seem to be a disagreement with the manual:
>
> http://www.php.net/manual/en/language.operators.errorcontrol.php
>
> There it says that you can stick before a variable name.
>
> miguel
--------------------------------------------------------
attached mail follows:
Hi Guys,
I have a problem wich I hope has been solved by someone :-)
Here's the deal,
I have to convert a perl script to PHP trying to do so I get negative
values from hexdec(), If I use (int)hexdec() the numbers aren't negative
anymore, but they do not add up to what they should.
Here's the perl line:
$a = FF ($a, $b, $c, $d, $temparr[8], $S11, hex("698098d8"));
this is PHP:
$a = FF ($a, $b, $c, $d, $temparr[8], $S11, hexdec("698098d8"));
FF is a function:
function FF($a,$b,$c,$d,$x,$s,$ac)
{
$a += F($b,$c,$d) + $x + $ac;
if ($a > hexdec("ffffffff"))
{
$a = substr($a,strlen($a)-9,9) ;
}
$a = RL($a,$s);
$a += $b;
return $a;
}
F is also a function:
function F($x, $y, $z)
{
return ((($x) & ($y)) | ((~$x) & ($z)));
}
Could anybody tell me what I am missing here?
e-mail: <mailto:frankhertogs.info> frankhertogs.info
attached mail follows:
>I have to convert a perl script to PHP trying to do so I get negative >values from hexdec(), If I use (int)hexdec() the numbers aren't negative >anymore, but they do not add up to what they should.
From the manual: http://php.net/hexdec "The largest number that can be converted is 7fffffff or 2147483647 in decimal."
I'm betting your numbers are bigger than that.
I wrote a less-limited hex2dec function years ago, and threw it up on Sklar, or, uhhh, the *other* PHP code repository. There were really only two, back then... :-)
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>:-) Don't tell me if you're gonna use it for production!!!
Depends on your user-base.
If all of them know that the only difference is $119, and all of them inherently trust your web-server and domain name to be correct, there is no more risk with the free one.
It's a true shame that the general public has been so mis-led and ill-informed on this issue. While there are a zillion descriptions of how the keys are exchanged, and how there are certificates here, there, and everywhere, few bother to explain how this whole "Trust" model really works.
A web-site pays $200, and they are trusted. End of story.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>On Fri, 5 Jul 2002, Richard Lynch wrote: >> But unless you paid the $200 to get it from a CA, surfers will see a nasty >> (and totally inaccurate/misleading) warning about how insecure it is. > >It is easy to launch a man-the-middle attack against a session being >initiated between a client and a server with a self-signed certificate. >You just send the client a self-signed certificate of your own, and it >can't tell it apart from the real one - same error message shows up.
"Easy" is relative.
What's more likely to occur:
A slime-ball with $200 makes a web-site to rip people off with a signed certificate. A hard-core hacker intercepts an HTTP connection.
Neither is a desired outcome.
The current Certificate Authority system works okay against the second one, but doesn't really address the first.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>>But unless you paid the $200 to get it from a CA, surfers will see a nasty >>(and totally inaccurate/misleading) warning about how insecure it is. >> > >They should. To do otherwise would be inaccurate and misleading. > >>The transmission is no less secure -- It's that the web-server on the other >>end was too cheap to pay the $200 for a CA key. >> > >No, the transmission is much less secure. You cannot be guaranteed the >identity of the Web server you're communicating with. You think just >because the HTTP transaction is encrypted that it is secure? What if >you're encrypted transaction is taking place with some criminal? You >still feel secure?
No, the *TRANSMISSION* is just as secure from snooping. It's the *RECIPIENT* whom you trust, or not. Maybe they've hijacked DNS records and are masquereding. Maybe they just didn't pay the $200. Maybe they paid $200 and are crooks.
Do you really believe that for $200 (or $119, or $500) that they "proven" themselves trustworthy?
>>Yes, the basic model for the security of all eCommerce is: >> >>"You pay some large corporation $200, and they trust you." >> > >No, you pay some large corporation money, because the majority of >browsers currently in use trust certificates issued by that corporation. >They've had to undergo extensive C&A processes to ensure the integrity >of their operation, and they've also had to shell out some big money to >Microsoft and Netscape to have their root certificates installed and >trusted into their browsers.
And for the $200, they do a background check on everybody, or what?
What's to stop a criminal from getting a $200 certificate? Nothing.
How do you *KNOW* that web-site isn't run by a criminal? How do you know they aren't collecting credit-card numbers? How do you *KNOW* they aren't storing them insecurely?
Fact is: All you *KNOW* is that they paid Thawte, Microsoft, or some other large corporation $200. You don't know *anything* else about them.
>>Alas, the *BROWSER* makes it sound like the whole thing is very shady, when, >>in reality, if you trust the web-site (certainly more than I trust >>Microsoft!) then it's just as secure. >> > >The browser *should* issue a warning when the identity of the Web server >it is about to communicate with cannot be guaranteed. You seem to be >confused about where the trust lies. If I trust the Web site >http://www.mybuddy.org/ (hypothetical best friend's Web site), does that >mean I should trust any certificate that is issued to www.mybuddy.org? >What if the certificate's root CA was a criminal's PC? Are you *sure* >that's your friend's Web site that you are communicating with?
If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate from a criminal's PC !!!
I *TRUST* them not to have non-repudiated Certificates floating around out there.
Conversely, if I don't know squat about mybuddy.org, all I know is they paid somebody else I don't trust $200.
Maybe you just trust big corporations more than I do. I dunno.
All I know is, the "Trust Model" *IS*
Somebody I don't trust pays somebody else I don't trust $200. Period.
Doesn't instill a lot of faith in the system for *ME*. Might be enough for you to have Faith, but not me.
>However, if you do trust a certain CA (perhaps your own), you can import >your root certificate into your browser and check some boxes to trust >it. Luckily, browsers don't even allow a method for you to "trust" a >domain name. > >It is quite trivial to generate a certificate for www.amazon.com. It >isn't too terribly difficult to make someone's computer think >www.amazon.com is your Web site. Here come the encrypted credit card >numbers. Good thing they're secure. :) > >The point is, PKI isn't about encryption alone. In fact, the "textbook" >answer to the question of what services PKI provides is: > >1. Identification >2. Authentication >3. Authorization >4. Integrity >5. Confidentiality >6. Non-Repudiation > >If it only provided confidentiality, quite honestly, PKI would be >useless as it is implemented today.
Do *YOU* trust the CA people to have thoroughly researched joesbotique.com when you give them your credit card?
How do you know it's not a scam?
How do you know their certificate hasn't been stolen, and they haven't even figured it out yet? How do you know they were trustworthy people in the first place?
You only *KNOW* that somebody, somewhere, at some time, paid $200 for that "Certificate" and that nobody has noticed something skanky about it -- at least not yet.
The more I think about this, the more I agree with people who just won't do eCommerce at all...
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
Richard,
Honestly, I think you need to just buy on book on this. I think I explained things pretty clearly, and your confusion now seems to be based more on a lack of trusting my explanation more than anything. I can't imagine how you could still be this confused.
I will try to explain once more for the benefit of readers who may be wondering if anything you said is true.
Richard Lynch wrote:
>No, the *TRANSMISSION* is just as secure from snooping. It's the >*RECIPIENT* whom you trust, or not. Maybe they've hijacked DNS records and >are masquereding. Maybe they just didn't pay the $200. Maybe they paid >$200 and are crooks. > >Do you really believe that for $200 (or $119, or $500) that they "proven" >themselves trustworthy? >
Now you've changed from "secure" to "secure from snooping." Notice the difference? It is significant. Like I said before, encrypting the transmission is useless by itself. To put it plainly:
encryption != security
What if you trust your friend who owns safeplace.org, and you want to do business with him? Maybe you visit his site and enter a credit card number somewhere. Thankfully, you notice that the lock icon is showing, and that he is using SSL. With this warped idea of SSL where encryption is all that counts, what if you find out that you're not really on safeplace.org? You're really at evilcriminal.org, and he has a virtual domain setup for safeplace.org. Also, he generated his own certificate for safeplace.org using his own CA (good thing there was not C&A process to undergo). So you have now sent the evil criminal your credit card number because you trusted his domain name. Good thing it's secure, right?
Hopefully it is clear that the trust in SSL relies on the trust of the certificate which relies on the trust of the root CA that issued that certificate. Trusting a domain name makes absolutely no sense.
>>>Yes, the basic model for the security of all eCommerce is: >>> >>>"You pay some large corporation $200, and they trust you." >>> >>> >>> >>No, you pay some large corporation money, because the majority of >>browsers currently in use trust certificates issued by that corporation. >>They've had to undergo extensive C&A processes to ensure the integrity >>of their operation, and they've also had to shell out some big money to >>Microsoft and Netscape to have their root certificates installed and >>trusted into their browsers. >> >> > >And for the $200, they do a background check on everybody, or what? > >What's to stop a criminal from getting a $200 certificate? Nothing. > >How do you *KNOW* that web-site isn't run by a criminal? How do you know >they aren't collecting credit-card numbers? How do you *KNOW* they aren't >storing them insecurely? > >Fact is: All you *KNOW* is that they paid Thawte, Microsoft, or some other >large corporation $200. You don't know *anything* else about them. >
This, I believe, is where your largest confusion lies. Read my first response to this again (quoted above). Did you read it? Read it again.
The C&A process is what someone like VeriSign undergoes, not the guy buying a certificate for evilcriminal.org.
>>The browser *should* issue a warning when the identity of the Web server >>it is about to communicate with cannot be guaranteed. You seem to be >>confused about where the trust lies. If I trust the Web site >>http://www.mybuddy.org/ (hypothetical best friend's Web site), does that >>mean I should trust any certificate that is issued to www.mybuddy.org? >>What if the certificate's root CA was a criminal's PC? Are you *sure* >>that's your friend's Web site that you are communicating with? >> >> > >If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate >from a criminal's PC !!! > >I *TRUST* them not to have non-repudiated Certificates floating around out >there. > >Conversely, if I don't know squat about mybuddy.org, all I know is they paid >somebody else I don't trust $200. > >Maybe you just trust big corporations more than I do. I dunno. > >All I know is, the "Trust Model" *IS* > >Somebody I don't trust pays somebody else I don't trust $200. Period. > >Doesn't instill a lot of faith in the system for *ME*. Might be enough for >you to have Faith, but not me. >
Alright, I'm starting to think you're trolling now. That might be funny on Slashdot, but it doesn't belong on this mailing list. I will clarify for those who need this information.
Here you are trusting a domain name again. That's a risky business, and luckily you didn't create a security model that anyone would implement on the Web. The same question arises yet again. How do you know that's the real mybuddy.org? Because it has a certificate from a CA that is not from a criminal's PC, right? How can you tell the difference between a CA from a criminal's PC and one from a place like VeriSign? Do you think it's just name recognition? Surely not. When you click past the warning that you seem to think shouldn't be there, do you check the fingerprint of the root CA first? If you do, and you trust it, just import the root certificate into your browser and trust it. Then you will have no more warnings from that certificate. Luckily, a certificate from a non-trusted CA issued to mybuddy.org will still display a warning.
Your browser has a default list of root CAs that it trusts. You can go look through them if you like. A certificate issued by a trusted CA to mybuddy.org is infinitely more secure than a certificate claiming to be issued to mybuddy.org from an unknown CA. If the browser treated both the same (which you seem to be suggesting), then no one would have any confidence in the identity of the Web server they are communicating with.
>>ver, if you do trust a certain CA (perhaps your own), you can import >>your root certificate into your browser and check some boxes to trust >>it. Luckily, browsers don't even allow a method for you to "trust" a >>domain name. >> >>It is quite trivial to generate a certificate for www.amazon.com. It >>isn't too terribly difficult to make someone's computer think >>www.amazon.com is your Web site. Here come the encrypted credit card >>numbers. Good thing they're secure. :) >> >>The point is, PKI isn't about encryption alone. In fact, the "textbook" >>answer to the question of what services PKI provides is: >> >>1. Identification >>2. Authentication >>3. Authorization >>4. Integrity >>5. Confidentiality >>6. Non-Repudiation >> >>If it only provided confidentiality, quite honestly, PKI would be >>useless as it is implemented today. >> >> > >Do *YOU* trust the CA people to have thoroughly researched joesbotique.com >when you give them your credit card? > >How do you know it's not a scam? > >How do you know their certificate hasn't been stolen, and they haven't even >figured it out yet? How do you know they were trustworthy people in the >first place? > >You only *KNOW* that somebody, somewhere, at some time, paid $200 for that >"Certificate" and that nobody has noticed something skanky about it -- at >least not yet. > >The more I think about this, the more I agree with people who just won't do >eCommerce at all... >
It's your job to trust joesboutique.com or not. How is any technology supposed to help you there? You want me to write a program to let you know which friends to trust, too? The CA simply assures you that it really is joesboutique.com and not some rogue Web site dressed up like joesboutique.com with his own SSL certificate trying to coerce you into "buying" things from his site.
As for stealing a certificate, how do you propose to do that? If you've ever installed an SSL certificate, you should be well aware that you must generate the request using your Web server. If anyone can install your SSL certificate on any Web server, why would this step be necessary? Think about it.
I think SSL was a truly revolutionary idea that is extremely secure. It irritates me to see such misinformation thrown around on a developer's mailing list like this just to get a few laughs.
Troll somewhere else.
Chris
attached mail follows:
ðÒÉ×ÅÔ!
Chris Shiflett wrote: > Richard, >> Do you really believe that for $200 (or $119, or $500) that they "proven" >> themselves trustworthy?
LOL no, I don't. As a matter of fact crooks usually have more money in their pockets than honest people do, so it's highly possible that a crook will pay the money while the innocent will save his last cent :))
> Now you've changed from "secure" to "secure from snooping." Notice the > difference? It is significant. Like I said before, encrypting the > transmission is useless by itself. To put it plainly: > > encryption != security > > What if you trust your friend who owns safeplace.org, and you want to do > business with him? Maybe you visit his site and enter a credit card > number somewhere. Thankfully, you notice that the lock icon is showing, > and that he is using SSL. With this warped idea of SSL where encryption > is all that counts, what if you find out that you're not really on > safeplace.org? You're really at evilcriminal.org, and he has a virtual > domain setup for safeplace.org. Also, he generated his own certificate > for safeplace.org using his own CA (good thing there was not C&A process > to undergo). So you have now sent the evil criminal your credit card > number because you trusted his domain name. Good thing it's secure, right?
So, let's see if I got you right:
1) SSL just says we our packets are difficult to open, that is, they are encrypted. Nothing more
2) Our packets are difficult to open but they are totally open to Uncle Sam's control software, as the RSA thingy cannot shield them from "governmental inspection", which makes sense if you are writing software for an american citizen but it's pretty annoying if your customer is from somewhere else.
3) A key is nothing more than a negotiation token, a mere building brick that is used to fire the process.
4) the "trust" you buy is something like a fixed IP number, that is the guys in the major do certify that you *are* who you pretend to be.
5) If the one I am pretending to be is a criminal, being trusted by Verisign (or whoever in their place) won't make any difference. Their "license" just means that you are really dealing with those you think you are dealing with and that they do bear legal responsibility for whatever will happen in the transaction. Again, legal action will eventually have different results depending on where the trusted company is based, since not all countries have the same normative set. But that has nothing to do with the SSL protocol in itself.
Now, there's a question regarding point 4). What if someone from www.goodguys.com gets the certified key pair and hands it over to some crook outside the company? I hope this is not just as easy as it sounds (the key pairs will probably check something in the environment before starting to shout "YEAAAH!! IT'S MEEE!!!") but still...
As for point 2), please get me right. I have my own political opinions as anybody else, but my concern here is a professional one, since my customers are 99% not americans. Small-mid sized companies (including mine) usually do not give a damn about having their messages read by american eyes (we are simply not worth the trouble of looking in our archives) but large companies and Govt. organizations are *much* less indifferent to the subject, and I guess it's understandable, they want their privacy to be for real.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
>Honestly, I think you need to just buy on book on this. I think I >explained things pretty clearly, and your confusion now seems to be >based more on a lack of trusting my explanation more than anything. I >can't imagine how you could still be this confused.
What I can't imagine is how confused you must think I am -- Since I'm not AT ALL confused.
>I will try to explain once more for the benefit of readers who may be >wondering if anything you said is true.
A great deal, nay all, of what I said was true.
Unfortunately, what you understood of it, was not true -- But that's not what I typed.
>>No, the *TRANSMISSION* is just as secure from snooping. It's the >>*RECIPIENT* whom you trust, or not. Maybe they've hijacked DNS records and >>are masquereding. Maybe they just didn't pay the $200. Maybe they paid >>$200 and are crooks. >> >>Do you really believe that for $200 (or $119, or $500) that they "proven" >>themselves trustworthy? >> > >Now you've changed from "secure" to "secure from snooping." Notice the >difference? It is significant. Like I said before, encrypting the >transmission is useless by itself. To put it plainly:
Notice how I first said *IN* *TRANSMISSION*.
Now, apparently, to *YOU* that wasn't sufficient to indicate: "while the packets are travelling from your browser to their destination".
When I first said "in transmission":
I did not mean "reaching the right destination"
I did not mean "the destination was worthy of trust"
I did not mean "reaching any destination at all"
I just meant "while the packets are travelling from your browser to their destination" (whatever that destination might be).
Somehow, you read that as "Definitely reaching the intended party, and the intended party being trusted"
Thus, I intentionally *ADDED* "secure from snooping" in my later post to clarify what *I* mean when I say "in transmission". I just mean "in transmission". Not reaching any particularly good nor bad end-point for that transmission.
I think we both agree that any old certificate is secure from snooping, right?
Now, since the only way I can see for it to be transmitted to the wrong party at all would be for the evil-doer to hijack the domain name as well as the SSL cert, I kinda figured it was a foregone conclusion the it was not the "transmission" at issue -- It's the *DESTINATION* at risk.
Apparently I should have spelled that out from the beginning, since you obviously misunderstood (and *still* misunderstand) my point.
>encryption != security
Obviously, since they aren't spelled the same way.
C&A SSL != security
either.
"More" secure than just encryption? I suppose... But not really enough more to inspire any real confidence in a C&A Signed Certificate.
>What if you trust your friend who owns safeplace.org, and you want to do >business with him? Maybe you visit his site and enter a credit card >number somewhere. Thankfully, you notice that the lock icon is showing, >and that he is using SSL. With this warped idea of SSL where encryption >is all that counts, what if you find out that you're not really on >safeplace.org? You're really at evilcriminal.org, and he has a virtual >domain setup for safeplace.org. Also, he generated his own certificate >for safeplace.org using his own CA (good thing there was not C&A process >to undergo). So you have now sent the evil criminal your credit card >number because you trusted his domain name. Good thing it's secure, right?
What if evilcriminal.org *STOLE* the C&A signed certificate from safeplace.org as well as hijacked their domain name?
What if evilcriminal.org set up safeplace.org and just *PAID* friggin' Microsoft for a C&A signed certificate in the *FIRST* place.
Yes, a C&A signed certificate is nominally "better" than a non-signed one, since you know that at some point, somebody paid somebody at least $119 (US), and that the certificate has the same domain name as the domain name of the computer you are now surfing to.
You don't know it's the same computer, though, right? It could easily be a stolen Cert and hijacked domain.
For that matter, you don't know that a CRIMINAL purchased the C&A signed Certificate in the first place.
I say again -- Do you *REALLY* believe that for $119, or even $500, that a complete background check is run on the people running all those web-sites with perfectly valid SSL Certificates that make the pretty lock icon close? I sure don't.
I consider a C&A Signed Certificate not significantly more reliable, trustworthy, nor "safe" than an unsigned one.
I don't trust the signers.
I don't trust that the people on the other end are who they say they are.
I have a low trust factor all around.
>Hopefully it is clear that the trust in SSL relies on the trust of the >certificate which relies on the trust of the root CA that issued that >certificate. Trusting a domain name makes absolutely no sense.
Sigh.
I'll say it again:
I don't trust a domain name.
I have an *EQUAL* distrust of a C&A signed certificate alleged to go with a domain name.
It's not that I trust a domain name so much -- It's that I trust the system of C&A signing so *LITTLE*
Are you reading what I'm typing? It sure doesn't sound like it...
You make it sound like I think it's perfectly safe to use a credit card on any old SSL link, C&A signed or not. No.
I *ALSO* contend that a C&A signed certificate *ONLY* proves:
example.com paid $$$ to somebody I don't trust, *OR*
example.com *STOLE* both the domain name and the SSL from somebody who paid $$$ to somebody I don't trust
Now, suppose I *REALLY* trust the people running example.com? So what?
I don't trust that they haven't been hijacked.
So I don't trust that their signed Cert is any more valid than their unsigned Cert, *BECAUSE* they could have had their domain name and their signed Cert stolen.
Hopefully, example.com would *DO* something about this situation immediately.
I sure don't trust the C&A folks to notice of their own volition.
Either I trust the folks at example.com to make sure their certs are not stolen, to make sure their domain is not scraped&hijacked, to make sure that any stolen certs are repudiated, or I don't trust them at all.
If I trust them to do all that, then they either watch their domain name *AND* their Certs like a hawk.
If they do that, then what "extra" trust is there in the C&A Signing by a company I don't trust? The people who made my *BROWSER* might trust those C&A signers, but *I* don't.
The only real added value is the repudiation of a C&A Signed cert -- which is not really worth a whole whole lot when I don't trust the C&A people to do their job right, now is it?
>>>>Yes, the basic model for the security of all eCommerce is: >>>> >>>>"You pay some large corporation $200, and they trust you." >>>> >>>> >>>> >>>No, you pay some large corporation money, because the majority of >>>browsers currently in use trust certificates issued by that corporation. >>>They've had to undergo extensive C&A processes to ensure the integrity >>>of their operation, and they've also had to shell out some big money to >>>Microsoft and Netscape to have their root certificates installed and >>>trusted into their browsers. >>> >>> >> >>And for the $200, they do a background check on everybody, or what? >> >>What's to stop a criminal from getting a $200 certificate? Nothing. >> >>How do you *KNOW* that web-site isn't run by a criminal? How do you know >>they aren't collecting credit-card numbers? How do you *KNOW* they aren't >>storing them insecurely? >> >>Fact is: All you *KNOW* is that they paid Thawte, Microsoft, or some other >>large corporation $200. You don't know *anything* else about them. >> > >This, I believe, is where your largest confusion lies. Read my first >response to this again (quoted above). Did you read it? Read it again. > >The C&A process is what someone like VeriSign undergoes, not the guy >buying a certificate for evilcriminal.org.
What *PROCESS* does evilcriminal.org have to undergo to get a certficate that will make the pretty lock icon "closed"?
1. Register a domain name. 2. Pay $119 3. Wait.
I don't *CARE* what process the the C&A companies went through.
Security is only as strong as the weakest link in the chain.
The weakest link here is:
*ANY* schmoe can pay $119 and get a C&A-Signed SSL cert.
I do *NOT* trust the C&A people did *ANY* real background check on that schmoe.
>>>The browser *should* issue a warning when the identity of the Web server >>>it is about to communicate with cannot be guaranteed. You seem to be >>>confused about where the trust lies. If I trust the Web site >>>http://www.mybuddy.org/ (hypothetical best friend's Web site), does that >>>mean I should trust any certificate that is issued to www.mybuddy.org? >>>What if the certificate's root CA was a criminal's PC? Are you *sure* >>>that's your friend's Web site that you are communicating with? >>> >>> >> >>If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate >>from a criminal's PC !!! >> >>I *TRUST* them not to have non-repudiated Certificates floating around out >>there. >> >>Conversely, if I don't know squat about mybuddy.org, all I know is they paid >>somebody else I don't trust $200. >> >>Maybe you just trust big corporations more than I do. I dunno. >> >>All I know is, the "Trust Model" *IS* >> >>Somebody I don't trust pays somebody else I don't trust $200. Period. >> >>Doesn't instill a lot of faith in the system for *ME*. Might be enough for >>you to have Faith, but not me. >> > >Alright, I'm starting to think you're trolling now. That might be funny >on Slashdot, but it doesn't belong on this mailing list. I will clarify >for those who need this information. > >Here you are trusting a domain name again. That's a risky business, and >luckily you didn't create a security model that anyone would implement >on the Web. The same question arises yet again. How do you know that's >the real mybuddy.org? Because it has a certificate from a CA that is not >from a criminal's PC, right? How can you tell the difference between a >CA from a criminal's PC and one from a place like VeriSign? Do you think >it's just name recognition? Surely not. When you click past the warning >that you seem to think shouldn't be there, do you check the fingerprint >of the root CA first? If you do, and you trust it, just import the root >certificate into your browser and trust it. Then you will have no more >warnings from that certificate. Luckily, a certificate from a >non-trusted CA issued to mybuddy.org will still display a warning.
Look, neither of us is saying anything new here.
I *UNDERSTAND* how this works.
I DO NOT TRUST THE C&A PEOPLE TO DO THEIR JOBS RIGHT
Okay?
I have *NO* *MORE* trust in them than I do in the guy I don't know at mybuddy.org
>Your browser has a default list of root CAs that it trusts. You can go >look through them if you like. A certificate issued by a trusted CA to >mybuddy.org is infinitely more secure than a certificate claiming to be >issued to mybuddy.org from an unknown CA. If the browser treated both >the same (which you seem to be suggesting), then no one would have any >confidence in the identity of the Web server they are communicating with.
Sigh. I treat them with *EQUAL* lack of confidence.
>>>ver, if you do trust a certain CA (perhaps your own), you can import >>>your root certificate into your browser and check some boxes to trust >>>it. Luckily, browsers don't even allow a method for you to "trust" a >>>domain name. >>> >>>It is quite trivial to generate a certificate for www.amazon.com. It >>>isn't too terribly difficult to make someone's computer think >>>www.amazon.com is your Web site. Here come the encrypted credit card >>>numbers. Good thing they're secure. :) >>> >>>The point is, PKI isn't about encryption alone. In fact, the "textbook" >>>answer to the question of what services PKI provides is: >>> >>>1. Identification >>>2. Authentication >>>3. Authorization >>>4. Integrity >>>5. Confidentiality >>>6. Non-Repudiation >>> >>>If it only provided confidentiality, quite honestly, PKI would be >>>useless as it is implemented today. >>> >>> >> >>Do *YOU* trust the CA people to have thoroughly researched joesbotique.com >>when you give them your credit card? >> >>How do you know it's not a scam? >> >>How do you know their certificate hasn't been stolen, and they haven't even >>figured it out yet? How do you know they were trustworthy people in the >>first place? >> >>You only *KNOW* that somebody, somewhere, at some time, paid $200 for that >>"Certificate" and that nobody has noticed something skanky about it -- at >>least not yet. >> >>The more I think about this, the more I agree with people who just won't do >>eCommerce at all... >> > >It's your job to trust joesboutique.com or not. How is any technology >supposed to help you there? You want me to write a program to let you >know which friends to trust, too? The CA simply assures you that it >really is joesboutique.com and not some rogue Web site dressed up like >joesboutique.com with his own SSL certificate trying to coerce you into >"buying" things from his site.
I have no confidence that a theif didn't steal both the domain name and the Cert, and, while we're at it, his whole damn web-server, lock, stock and barrel.
I have no confidence the C&A people would notice.
I have no confidence the C&A people would do a good job of doing something useful in a timely fashion if if they were notified.
I don't trust the C&A people. I don't trust the people who trust the C&A people.
I don't even trust you :-)
The C&A Signed Cert with the pretty little lock icon has NO MORE trust factor for me than an unsigned home-brewed SSL connection. They are equally un-trustworthy.
Are you understanding me yet?
Will you at least stop claiming that I trust a domain name?
How about this: I don't trust my mother. And she's dead. Is that clear enough?
>As for stealing a certificate, how do you propose to do that? If you've >ever installed an SSL certificate, you should be well aware that you >must generate the request using your Web server. If anyone can install >your SSL certificate on any Web server, why would this step be >necessary? Think about it.
Work with me here, okay?
I steal his SSL certificate. I steal his domain name. I put them on my own web-server.
When/how do the C&A people catch this?
I either trust the DOMAIN NAME owner to *DO* something about this *WHEN* it happens, or I don't trust the site.
The signed/unsigned SSL connections are *EQUALLY* untrustworthy *BECAUSE* I don't *KNOW* for 100% certain that the recipient is *really* the guy I trust.
Now, here's the crux of the matter, which, every time you read it, you think I "trust" a domain name not getting hijacked by a crook, which I don't:
If I *really* trust the person who owns a domain name, they are going to take care of any hijack/theft just as quickly with an unsigned cert as they are with a signed cert. I don't trust the C&A people to facilitate that process any faster or better than somebody I actually *DO* trust in the first place -- The person I personally know who owns that domain name who is going to make damn sure they catch and rectify any hijacking with or without a signed Cert as fast as possible. I trust that person because I know them, not the C&A people I don't know personally, and who have *PROVEN* themselves untrustworthy. I trust people, not corporations, not technology, and *CERTAINLY* not the C&A Signers.
If a person I *TRUSTED* chose to have an unsigned C&A Cert -- I would trust them. Not because their site couldn't be hijacked. But because I trust them to do the right thing if it was. Not because I think my credit card isn't at risk, but because the risk is NO HIGHER with the unsigned Cert. The signed/unsigned Cert are *equally* untrustworthy to me.
Do you *really* understand what I'm saying? Because if you do, you'd agree with me instead of arguing that C&A Signed Certificates are significantly more trustworthy when you have 0 trust in the person holding the Certificate in the first place. I don't even trust the folks *issuing* the C&A Certs, much less some guy I never met who happens to be holding it and a domain name that matches. Or, at least, *I* have 0 trust in some schmoe who sets up a web-site. I've had to debug enough of them with horrible security to know just how bad it could be.
Put it into real-world terms:
Let's compare two equally good used cars.
Car A is from a licensed used car dealer, which has gone through the same business license process as every other licensed used car dealer.
Car B is from a person you personally know and trust.
Which car you gonna buy? Do you trust that used car dealer simply because they have a lot and a piece of paper from the government?
Maybe you're the kind of guy who buys from a used car lot instead of a friend, because you think that's safe. I'm not. It's that simple. The two cars are equally likely to crap out on me, but if they do, I have a lot more trust in my friend making it right with me than some used car lot I don't know.
>I think SSL was a truly revolutionary idea that is extremely secure. It >irritates me to see such misinformation thrown around on a developer's >mailing list like this just to get a few laughs.
I'm not laughing.
I'm not trolling.
Nothing I said was false. You may have mis-understood it, but it wasn't false.
The "Security Model" of SSL and C&A signed certificates gives me little "trust" in the system.
Maybe it's the best anybody can come up with. Still not inspiring confidence for me.
Hopefully, at this point, you actually understand what I typed in the first place.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
Alberto Serra wrote:
> ðÒÉ×ÅÔ!
I've always wondered what this is exactly. I'm going to assume it's a friendly greeting. :)
> Chris Shiflett wrote: > >> Richard, >> >>> Do you really believe that for $200 (or $119, or $500) that they >>> "proven" >>> themselves trustworthy? >> > > LOL no, I don't. As a matter of fact crooks usually have more money in > their pockets than honest people do, so it's highly possible that a > crook will pay the money while the innocent will save his last cent :))
Please watch the attribution here. I never posed that question (Do you really believe ...), as it is very misleading and would indicate that I have very little knowledge about PKI systems, which is not the case. I know that the purchase of a certificate from a trusted Certificate Authority is a very important part of the security that SSL provides, and I would not pose a rhetorical question in a weak attempt at trivializing this.
>> Now you've changed from "secure" to "secure from snooping." Notice >> the difference? It is significant. Like I said before, encrypting the >> transmission is useless by itself. To put it plainly: >> >> encryption != security >> >> What if you trust your friend who owns safeplace.org, and you want to >> do business with him? Maybe you visit his site and enter a credit >> card number somewhere. Thankfully, you notice that the lock icon is >> showing, and that he is using SSL. With this warped idea of SSL where >> encryption is all that counts, what if you find out that you're not >> really on safeplace.org? You're really at evilcriminal.org, and he >> has a virtual domain setup for safeplace.org. Also, he generated his >> own certificate for safeplace.org using his own CA (good thing there >> was not C&A process to undergo). So you have now sent the evil >> criminal your credit card number because you trusted his domain name. >> Good thing it's secure, right? > > > So, let's see if I got you right: > > 1) SSL just says we our packets are difficult to open, that is, > they are encrypted. Nothing more
NO! :)
That's what some other guy was trying to say. He is wrong.
SSL does much more than encrypt the communication. Part of my response was a bit satirical in a weak attempt at pointing out how ridiculous a notion this is. I guess it didn't help very much. :)
Note the use of the phrase, "With this warped idea of SSL where encryption is all that counts...."
I apologize for adding to the confusion there. I was trying to point out how insecure this model would be if encryption were all that SSL provided and the only trust involved was the trust of a domain name.
> 2) Our packets are difficult to open but they are totally open > to Uncle Sam's control software, as the RSA thingy cannot > shield them from "governmental inspection", which makes sense > if you are writing software for an american citizen but > it's pretty annoying if your customer is from somewhere else.
No government, as far as I know, can break the public key cryptography currently being used by most SSL-enabled sites (using the strong security - 128 bit certificates). This includes the United States.
Now, SSL only encrypts your communication in transit, of course. I'm sure your local government could find a way to make the entity you are communicating with release the information in the communication to them. This is, of course, outside the scope of SSL.
> 3) A key is nothing more than a negotiation token, a mere building > brick that is used to fire the process.
A key, when spoken of as one entity, is a key pair. It contains both the public and private keys. The use of these in cryptography is called asymmetric cryptography. To understand asymmetric cryptography, it is helpful to first explain what symmetric cryptography is.
Symmetric cryptography is basically the use of a single key for the encryption and decryption. Most two-way encryption algorithms you are probably familiar with use this approach. For two people to effectively encrypt their communication with this approach, it is necessary for both parties to have the same key. To submit this key over the Internet would be a poor idea, because it could be intercepted, right? Ironically, most keys for use with symmetric cryptography are distributed over the Internet using asymmetric crptography. :) Others use some sort of physical transfer, like meeting each other on a dark street corner with a briefcase. :)
The problem with trying to use this type of approach to encrypt communication between a Web client and a Web server is pretty clear. If your customers can be anyone, then anyone must have access to the key. Thus, all of your customers would be able to decrypt communication from all of your other customers. Otherwise, if each client's communication was encrypted using a different key, you would have to have a separate key for each client, *plus* you would have to have a secure way to receive these keys on the initial transaction in a timely manner. This poses a real challenge.
The solution is asymmetric cryptography (public key cryptography). With this approach, each party has a key pair. The cryptography is quite advanced, and I've only begun to comprehend the generation of the keys myself. However, it is adequate to know that one key is used to do the encrypting, while the other is used for the decrypting. These are generally referred to as public and private keys, because one is made available to the public while the other is kept safely stored (in the case of Web browsers, it is stored in the certificate repository of the browser).
To see how this helps solve the problem of securing Web transactions, remember that both the Web client and the Web server possess a key pair. Thus, we have four keys:
1. Web server's public key 2. Web server's private key 3. Web client's public key 4. Web client's private key
Items 1 and 3 are exchanged in the initial SSL handshake. This takes place prior to the HTTP request being transmitted. Because information encrypted with the public key can only be decrypted with the corresponding private key, the basic exchange works like this:
1. All HTTP requests are encrypted with item 1, so that only item 2 can be used to decrypt them. 2. All HTTP responses are encrypted with item 3, so that only item 4 can be used to decrypt them.
With this method, the only entity that can decrypt the HTTP request is the Web server receiving the request, and the only entity that can decrypt the HTTP response is the Web client that sent the original request.
This overview only covers how the cryptography is made secure. Remember, PKI provides the following assurances:
1. Identification 2. Authentication 3. Authorization 4. Integrity 5. Confidentiality 6. Non-repudiation
So, we have effectively only described how item 5 is achieved.
I do not have the time to explain each of these items in as much detail, but the most important topic of the things left is item 1, identification, which is alluded to in your next question.
> 4) the "trust" you buy is something like a fixed IP number, that is > the guys in the major do certify that you *are* who you pretend > to be.
The trust I spoke of in my earlier response dealt with identification. If you cannot guarantee the identity of the entity with which you are communicating (whether the communication is encrypted or not), then your communication is very insecure.
Digital certificates solve this problem. A digital certificate, as RSA describes it, is a document that says:
"I guarantee that this particular public key is associated with this particular user; Trust me!"
So, assuming for the moment that we trust the certificate, we can assume that a particular public key belongs to a particular user. For example, you can be guaranteed that a public key belongs to me (Chris Shiflett) and thus, only Chris Shiflett will be able to decrypt the communication. If someone is trying to pose as me, you may send them encrypted communication, but they won't be able to decrypt it.
> 5) If the one I am pretending to be is a criminal, being trusted by > Verisign (or whoever in their place) won't make any difference. > Their "license" just means that you are really dealing with those > you think you are dealing with and that they do bear legal > responsibility for whatever will happen in the transaction. > Again, legal action will eventually have different > results depending on where the trusted company is based, since > not all countries have the same normative set. But that has > nothing to do with the SSL protocol in itself.
Well, I disagree that this has nothing to do with the SSL protocol itself. Identification is a very important part of enabling secure transactions to take place over the Web. Without this, there would be no "ecommerce" as it has been dubbed.
The role companies like VeriSign play goes back to the assumption we made above, where we assumed the digital certificate to be trustworthy. Since a digital certificate guarantees us that a specific person is associated with a specific public key, we must trust this certificate in order to trust the association. In the case of HTTP transactions, the entity that needs to trust the (SSL) certificate is the browser. Browsers come with a whole group of Root certificates that are trusted by default, and any digital certificate issued by these CAs are thus trusted. Any certificate issued by a trusted CA is going to claim something like the following:
"I guarantee that this particular public key is associated with this particular domain name; Trust me!"
So, when our browser communicates with goodguy.org, it uses this guarantee to make sure that only the *real* goodguy.org can decrypt the communication. If someone at badguy.org tries to impersonate goodguy.org, this guarantees us that they will not be able to encrypt the communication.
Of course, as users of Web browsers such as Netscape and Internet Explorer, we have to trust AOL/Time Warner and Microsoft, respectively, (yeah, scary thought) to only trust CAs that have high integrity, security, etc. An extensive C&A (Certification and Accredidation) process is used to make this guarantee.
> Now, there's a question regarding point 4). What if someone from > www.goodguys.com > gets the certified key pair and hands it over to some crook outside > the company? I hope this is not just as easy as it sounds (the key > pairs will probably check something in the environment before starting > to shout "YEAAAH!! IT'S MEEE!!!") but still...
This would be a scary thought. Luckily it's not possible. A key pair is unique per Web server, right? Well, recall that the digital certificate only guarantees that a certain public key belong to a certain entity (in this case, a Web server). In order to make this association in the first, a request for an SSL certificate must be created by the Web server intended to be used to service that particular domain name, and adequate proof that you are the rightful owner of the domain name is also required. Without this, the CA wouldn't know which public key was *definitely* yours, so it couldn't, in good faith, create the digital certificate.
So, for your above scenario to work, the crook outside the company would have to be handed the actual Web server software as it is currently compiled (for example, hand him the whole physical server) to be able to use that digital certificate. In addition to this, the crook would also need to trick someone's computer into resolving the domain name to be *his* IP address rather than the real one. With all of these things in place, the browser connecting to the crook's site with SSL would not issue a warning. In practice, however, not only is this extremely hypothetical, but the people at www.goodguys.com would surely have found out about this (their Web site is gone, all of a sudden) and notified the CA. The digital certificate would be revoked, so it would no longer be valid.
Why does revoking it do any good? Remember, there is a chain of trust. To trust a digital certificate requires that you trust the CA from which it was generated. When done with software rather than people, a check is made with the CA to make sure this certificate is still valid.
> As for point 2), please get me right. I have my own political opinions > as anybody > else, but my concern here is a professional one, since my customers > are 99% > not americans. Small-mid sized companies (including mine) usually do > not give a > damn about having their messages read by american eyes (we are simply > not worth the trouble of looking in our archives) but large companies > and Govt. organizations are *much* less indifferent to the subject, > and I guess it's understandable, they want their privacy to be for real.
I understand the concern. However, like I said, regardless of political policies, you can be assured that the communication cannot be decrypted, tampered with, etc. Political entities could put pressure on the recipient of the communication to reveal it, but that is all. Of course, the US government may have figured out how to break 128 bit public key cryptography, but I seriously doubt it.
This just skims the surface on PKI and SSL. I hope it at least clarifies a few things, because there was a lot of misinformation being thrown around earlier.
Happy hacking.
Chris
attached mail follows:
I just explained this all in great detail, so please read that. I don't just think you are confused; I am positive you are.
However, I did notice that you are the same person who gives many good answers to other peoples' questions. This giving of your time to be helpful is commendable, and I apologize for mistaking you for a troll. I just honestly don't understand the confusion.
I'll only correct a couple of points that you seem to keep bringing up that are incorrect. I believe these might be the root of all confusion.
Richard Lynch wrote:
>Work with me here, okay? > >I steal his SSL certificate. >I steal his domain name. >I put them on my own web-server. > >When/how do the C&A people catch this? >
In public key cryptography, it is the *keys*, not the digital certificate that encrypt/decrypt the communication.
In your example above, how do you propose stealing "his" private key? It is in his Web server, right? You have his digital certificate, but that only guarantees that his pulic key is associated with his domain name. Even if you can "steal" his domain name and somehow get traffic going to you, you can't decrypt the communication without the private key. This is why I tried to explain the necessity of generating the request for a digital certificate from the Web server that it will be installed on. If you steal his entire server as well and he doesn't report it to the CA that issued his certificate, he may as well let you run your rogue site off of his server; it's the same difference.
Think of it this way. Let's use https://www.amazon.com/ as an example. Do you trust doing business with them? I sure do; at least I trust 100% that my HTTP requests are going to get to the www.amazon.com server safely. If someone stole their SSL certificate:
1. They wouldn't be able to install it on any other Web server anyway (your item 3 above is invalid) 2. It only guarantees that Amazon's public key really belongs to www.amazon.com - we knew that already
So, you've done nothing.
Now, on to "stealing" their domain name. All of a sudden, Amazon is getting no traffic. Think they won't notice? Think it matters since the HTTP requests you'll be receiving can't be decrypted by you anyway?
>If I *really* trust the person who owns a domain name, they are going to >take care of any hijack/theft just as quickly with an unsigned cert as they >are with a signed cert. I don't trust the C&A people to facilitate that >process any faster or better than somebody I actually *DO* trust in the >first place -- The person I personally know who owns that domain name who is >going to make damn sure they catch and rectify any hijacking with or without >a signed Cert as fast as possible. I trust that person because I know them, >not the C&A people I don't know personally, and who have *PROVEN* themselves >untrustworthy. I trust people, not corporations, not technology, and >*CERTAINLY* not the C&A Signers. >
This is the other major misunderstanding. How is your friend supposed to "take care of any hijack/theft" exactly? If someone "hijacks" all of his traffic, sure, he might notice a lack of traffic. However, what if only a small audience is targetted? A few people mistakenly go to the wrong www.friend.org site and do business. If there was no SSL warning letting them know that something was wrong, they would happily do business.
Your friend may be the best Web surfer in the world, but I doubt he can keep up with every Web site on the Web at all times to make sure that no one else is impersonating him. He has to rely on the technology, and that technology is SSL.
That's all for me. I'm going to start charging you for more information about SSL. :) I still strongly suggest you read a book. I even suggested a single 50 page chapter that will probably clarify everything for you. You seem to think you have a grasp about what is going on, but I can assure you that you don't.
I don't know how much clearer I can get. I've got other work to do.
Cheers.
Chris
attached mail follows:
>I can't seem to upload file bigger than 5M even if I set the >upload_max_filesize to 20M in php.ini and MAX_FILE_SIZE to 20M in the >script. What's am I missing here? Is the temporary upload directory won't >handle file this size? Please give me some pointers here. TIA.
Does <?php phpinfo();?> show a 20 M limit?
Is it using the php.ini file you think it's using?
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>Stored procedures are like any other type of programming construct. >You can do them right or you can do them wrong.
Yeah, and GOTO is perfectly fine... In the right place.
>When making a stored >procedure you should stick to ansi SQL as much as possible.
All my SQL was so dirt-simple, it couldn't have been non ANSI.
select name, skill from applicants where job_id = $job_id
>Most of >my stored procedures I can move from a SQL Server 2000 box to an Oracle >8i box with not problems at all.
Oh they *MOVED* okay. Now update the Stored Procedures for sub-section A of your on-line application on the Development box, and try to push the changes through to the Production Server.
So, which Stored Procedures got changed?
You have to keep track of them all, cuz MS sure doesn't.
>Stored procedures are NOT over head.
They are a *LOT* of painful administrative overhead, and their gains are mythical, not real.
>If you need to change an SQL statement, then you would have to search >through all your code to make changes intstead of just one stored proc.
Bullshit.
If I have to change an SQL statement, I know right where it is, right where it belongs, right in the code.
>If you don't see any speed increase from stored procs then you are doing >something wrong. Stored procs are compile SQL statements. Every >time a your php page does something like $query="Select * from MyTable" >the DB needs to parse the query and create an execution plan.
Do you have *ANY* idea how quickly:
"select * from MyTable" can be parsed and an execution plan selected?!
It's CHUMP CHANGE in time.
*ONLY* if your SQL is so incredibly complicated that you can't even understand it will the parse/compile time of SQL be a factor in performance.
>The stored >procs do it only ONCE the first time it is ran and all the other calls to >it save you many millisecond to seconds. That might not sound like much >but if you have a site with more than 5 users you will see a difference. >The intranet I finished for my company has 100,000 users and sustains >almost 1,000 users per second. The pages took 7 to 10 seconds without >stored >procs and went down to 3-4 seconds with them.
*NOTHING* else changed, except you went to stored procedures?...
I'm from Missouri. Show me.
>Also, new features needed to >be >added to the site and required some tables to be changed. I only had to >change >one SQL in on location and everything was fine.
I only have to change one SQL in one location, and everything is fine.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
On Sat, 06 Jul 2002 15:27:47 -0500
"Richard Lynch" <richphpbootcamp.com> wrote:
> Do you have *ANY* idea how quickly: > > "select * from MyTable" can be parsed and an execution plan selected?! > > It's CHUMP CHANGE in time. > > *ONLY* if your SQL is so incredibly complicated that you can't even > understand it will the parse/compile time of SQL be a factor in > performance.
It is "CHUMP CHANGE" when you make a tinie web site with 2 users. Do the math. If you have a SQL statement that takes 250 milliseconds to parse and create an execution plan, then 250 * 1,000,000 page request per week (which is what the site I finished averages, the company I work for has 110,000 employees) = ??? This is second grade math.
No matter how you look at it, 10 extra milliseconds here or there adds up when you work on a big site. The db's I work with are not simple "select foo from bar" queries. An enterprise db is usually pretty complex. My main reason for posting a reply was not to start a stupid flame war with you. It was from stopping you from filling the heads of new programmers on this list with bunk. Stored procedures are not junk! I wonder why they are the most requested feature for MySQL? Why would all the Big DB's (Oracle, DB2, PostgreSQL, SQL Server, etc.) support them if they had no benifit? The biggest benifit is SPEED, the second is the ability to encapsulate the underlying database structure. A DBA can change the db structure at will as long as the sproc returns the same columns.
-- James Drabb JR - Programmer Analyst - Orlando, FL - JDrabb
attached mail follows:
>i`ve coded a mass-mailer for my site but the $from header doesn't work.
It works for about a million others. Show us source code.
>when i get a test message back from it it says from "Unprivileged user" = >not what i set it to.
That sounds more like email bouncing...
But it could be your sendmail/qmail/exim/fredmail telling you that the User (see httpd.conf) that PHP runs as (see <?php phpinfo();?>) doesn't have permission to "forge" email from some other address.
In which case your PHP syntax is fine, but your mail-sending MTA thingie is not configured correctly.
>How would i set it out using the syntax: > >$to # >$from # >$subject # >$message # #>mail($to, $from, $subject, $message)
$success = mail($to, $subject, $message, "From: $from\r\nReply-to: $from\r\n"); if (!$success){ print("Failed to send email to $to with subject $subject<BR>\n"); }
>_______________________________________________=20 > >Also, i was wondering how i could use my own PHP.INI config file on a = >remote webserver which hosts my site.
Not usually, but most of the settings you have any right to change are changeable in .htaccess
>And can i set .php to something else, like .he for example?
For example, create a file in your web directory, right next to your HTML files, and name it ".htaccess" (Yes, the "." is part of the name.)
Put this in it:
AddType application/x-httpd-php .he
Assuming your ISP used the *standard* mime-type (application/x-httpd-php) all your .he files are now being handled by the PHP Module.
If your ISP didn't use the standard mime-type, you have to ask them what they used.
If they don't understand the question (scary, but happened to me once) tell them to do:
grep -i php httpd.conf
and send you the output.
Disclaimer: The ISP in question may actually have simply mis-understood the question the first time around, and didn't have to actually send me all the output of the grep on the second go-around...
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>Re: help help help!!!!!!pls........
First, use a valid subject. Experts will simply hit "Delete" for such vague subjects as "Help"
>I have multiple check boxes ...and I gave the single name to all check >boxes..... > >If I post to my php script I am not getting all the values as an >array.....I am getting only one value(last value).....
Second, read the FAQ.
Third, you are correct. :-)
PHP needs [] in order to automatically build the nifty array of values on the PHP side.
JavaScript will not, no matter how hard you try (I tried *everything*) allow you to force [] into the Name of an object.
Your choices are: 1. In JavaScript, refer to the objects by position, not name. document.form1[1].checked or whatever
2. In HTML/JavaScript provide and ID=xxx attribute, and refer to objects by ID. Never tried it, don't even know what an ID is if it's not a name, and can't promise it will work, but that's what somebody said *LAST* *WEEK* on this list.
3. Don't use [] in HTML, and in PHP tear apart the $REQUEST_URI yourself, by hand. Wouldn't recommend this last one, but it would work. Put <?php phpinfo();?> into your php script that accepts/process the POST, and you'll see which variables have the checkbox names in them. A little http://php.net/explode and iteration, and you're done.
Please re-read the FAQ, though, as this question is addressed in there, so it must be time for you to re-read it.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
>I have been going fine in a Web Stats program until now. > >How can I figure out which day has had the most records(ie visitors) >inserted? > >There is a time column which has unix timestamp of when the record was >inserted. > >The best I can think of currently is: >To use a while loop to repeatedly query the DB. >then use an if statement to replace two variables(UNIX timestamp and number >of visitors) if the value returned is higher.
Almost any time you do a while loop to repeatedly query the DB, you've done something wrong. :-)
Either you are missing an SQL function that will do what you want, or you just designed the db schema wrong and the application wrong in the first place.
Fortunately, in this case, you're just missing an SQL function.
Dig through the manual of your database (you didn't say which one) in the Date/Time functions section, and see if you can find one that will extract the year and month from a timestamp.
You'll end up writing something not unlike this:
select count(*) as monthly_views from visitors group by extract('year', whattime), extract('month', whattime) order by monthly_view desc limit 1
The GROUP BY part is the "magic" -- It will do any "aggregate" function (count, average, sum) broken down by whatever fields are listed. In this case, I broke it down by year & month.
If you wanted the most popular month over the last five years, it would be something not unlike:
select count(*) as monthly_views
from visitors
where whattime + ' 5 years' >= now()
group by extract('month', whattime)
order by monthly_view desc
limit 1
Disclaimers:
1. 'extract' is probably not the right function name. You'll have to look
that up.
2. The "whattime + ' 5 years'" works just nifty in PostgreSQL. You have to
type more than that in MySQL, I think... MySQL date arithmetic always gives
me a pain.
Always dig for a way to do it in SQL first.
-- Like Music? http://l-i-e.com/artists.htm
attached mail follows:
Here is my code:
<? $query = "select count(*) as monthly_views from visitors group by extract('year', time), extract('month', time) order by monthly_view desc limit 1"; $result = mysql_query($query); $num_results = mysql_num_rows($result); echo $num_results; echo mysql_error(); ?>
When I execute it I get this error:
Warning: Supplied argument is not a valid MySQL result resource in C:\Inetpub\TecEco_PHP\stats_interface\summary.php on line 75 You have an error in your SQL syntax near ''year', time), extract('month', time) order by monthly_view desc limit 1' at line 1
I don't know any advanced SQL so can't really debug it.
Could someone tell me what I am doing wrong please?
-- JJ Harrison webmaster"Richard Lynch" <rich
attached mail follows:
Hey group,
I have set up iptables based on the BLFS book. I have a rule like: # Log everything else: What's Windows' latest exploitable # vulnerability? $IPTABLES -A INPUT -j LOG --log-prefix "FIREWALL:INPUT " The output is going into /var/log/kern.log is there anyway I can send it to a seperate file say /var/log/firewall.log?
Thanks,
Jim Drabb
-- James Drabb JR - Programmer Analyst - Orlando, FL - JDrabb
attached mail follows:
Opps, I sent to the wrong list : )
Sorry,
Jim Drabb
-- James Drabb JR - Programmer Analyst - Orlando, FL - JDrabb
attached mail follows:
Does MySQL support parameterized queries (e.g., "INSERT INTO table (Col1,Col2) VALUES (?,?)"), and if so, is there a PHP function that allows you to create and attach parameters to MySQL queries?
Thanks, Henry
attached mail follows:
Hi all. Im getting the above mentioned error: *Parse error*: parse error, unexpected $ in *c:\program files\apache group\apache\htdocs\login.php* on line *38* when I try to view the page I just created. As a forewarning, I am very new to PHP, so I may have done something stupid, and if it matters, I am also using windows, not *nix. Any help with this would be greatly appreciated.
attached mail follows:
that error appears many times to me...you can show some code so we all can see what's wrong, but i've solved it adding a }, as i told you, manny times it has appear to me, and that's the way i've solved it :D
>From: Shiloh Madsen <shiloh_madsennsc-support.com>
>To: php-generallists.php.net
>Subject: [PHP] Error: Parse error: parse error, unexpected $ in...
>Date: Sat, 06 Jul 2002 20:03:35 -0500
>
>Hi all. Im getting the above mentioned error: *Parse error*: parse error,
>unexpected $ in *c:\program files\apache group\apache\htdocs\login.php* on
>line *38* when I try to view the page I just created. As a forewarning, I
>am very new to PHP, so I may have done something stupid, and if it matters,
>I am also using windows, not *nix. Any help with this would be greatly
>appreciated.
>
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
_________________________________________________________________ Únase al mayor servicio mundial de correo electrónico: http://www.hotmail.com/es
attached mail follows:
Firstly, I apologize if this has already been asked in the past; I've not been a regular reader of this list and I couldn't find mention of my problem after a cursory search of the archives (which are a bit overwhelming to search exhaustively)...
On one of my machines, I'm running PHP 4.1.2. On another machine, I'm running 4.2.1. The script I'm having problems with runs fine under 4.1.2, but fails to work under 4.2.1.
What my script is doing is live file system browsing. Over-simplified, it reads a directory of files, then makes everything it finds active links to be downloaded, or directories to be browsed. I pass everything back to the script using $PHP_SELF, so there's no CGI or "forms" involved in the transaction. The URL after browsing down a directory, and being parsed and returned to the browser, would look something like this:
http://myserver/index.php?dir2=somedirectory
In 4.1.2, if I echo $dir2 at the beginning of the script just for testing, it will echo the value of the variable without issue. In 4.2.1, the variable never appears to get set at all, although it does show up just the same in $QUERY_STRING under both versions of PHP, so I know something is at least being passed back to the server.
Does this make sense how I explained it? Can anybody tell me what's changed between versions that would make the script (or, really, PHP) ignore the value I'm passing back? (I looked at the changelog, but didn't really see anything that I understood to be related to the problem I'm experiencing.)
TIA, Jamie
attached mail follows:
Jamie Novak said:
> On one of my machines, I'm running PHP 4.1.2. On another machine, I'm > running 4.2.1. The script I'm having problems with runs fine under > 4.1.2, but fails to work under 4.2.1.
> http://myserver/index.php?dir2=somedirectory
> In 4.1.2, if I echo $dir2 at the beginning of the script just for > testing, it will echo the value of the variable without issue. In > 4.2.1, the variable never appears to get set at all, although it does > show up just the same in $QUERY_STRING under both versions of PHP, so I > know something is at least being passed back to the server.
php.ini > register_globals
-- Jason Wong -> Gremlins Associates -> www.gremlins.com.hk
attached mail follows:
On 07/06, Jason Wong rearranged the electrons to read: > php.ini > register_globals
Well, that was simple and stupid. :/ Thank you for the prompt reply. Obviously, that did the trick.
- Jamie
attached mail follows:
ðÒÉ×ÅÔ!
Jamie Novak wrote: > http://myserver/index.php?dir2=somedirectory > > In 4.1.2, if I echo $dir2 at the beginning of the script just for > testing, it will echo the value of the variable without issue. In > 4.2.1, the variable never appears to get set at all, although it does > show up just the same in $QUERY_STRING under both versions of PHP, so I > know something is at least being passed back to the server. > > Does this make sense how I explained it? Can anybody tell me what's > changed between versions that would make the script (or, really, PHP) > ignore the value I'm passing back? (I looked at the changelog, but > didn't really see anything that I understood to be related to the > problem I'm experiencing.) > > TIA, > Jamie >
You did look for a leaf and missed the tree :)) Look for Register_globals in your php.ini file. It's *off* in the new versions and it should be so for security reasons. Just check the docs in the online manual and everything will be clear :))
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
Jimmy Lam said:
> I am a new bie here and I would like to know more about coding in > upload photo file by client side and store in mysql database. also , > how can I show the photo in the HTML CODING embeded and get the > image directly from the database ? thanks . could you mind provide > some code to let me reference. ?? I am doing my project. I need this > information in urgent. Please friendly give me advice here . thanks
Search archives for "upload mysql"
-- Jason Wong -> Gremlins Associates -> www.gremlins.com.hk
attached mail follows:
I am trying to build a "product detail" page that pulls data from a MYSQL database using PHP. The data for the page includes product images, which I am trying to link to (i.e. from their location on the web server) instead of loading the images into the database. However, I cannot find any sample code that seems to work. Two questions:
1. Is this possible (i.e. to store the HYPERLINK to the image in the database , and as the results are returned to the product detail screen, the image file will be displayed)? OR RATHER do I need to store the physical image file in the database location and query it that way?
2. The code sample below contains several lines that show a field populated with text that I am returning....the line under the //Test comment is the field that I'm trying to pull an image back for:
printf("REL_PLAN7: %s<br>\n", mysql_result($result,0,"REL_PLAN7")); printf("REL_PLAN8: %s<br>\n", mysql_result($result,0,"REL_PLAN8")); printf("REL_PLAN9: %s<br>\n", mysql_result($result,0,"REL_PLAN9"));
//test printf(mysql_result($result,0,<a href="FRONT_REND">FRONT_REND</a>);
NOTE: "FRONT_REND" is the name of the database field, and it contains a full web address, not relative.
Any help would be GREATLY appreciated. Thanks.
Mark
attached mail follows:
ðÒÉ×ÅÔ!
Probably a stupid question. Is there anyway to force POSTing a form from the refresh META?
<META HTTP-EQUIV="Refresh" CONTENT="2;URL=someURL/somescript.php">
IMHO that is NOT possible, but maybe I am wrong.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
not from meta refresh. but javascript could do that. set a timeout that will fire the submit event after 2 seconds. that will work.
b.c. lance
Alberto Serra wrote: > ðÒÉ×ÅÔ! > > Probably a stupid question. Is there anyway to force POSTing a form from > the refresh META? > > <META HTTP-EQUIV="Refresh" CONTENT="2;URL=someURL/somescript.php"> > > IMHO that is NOT possible, but maybe I am wrong. > > ÐÏËÁ > áÌØÂÅÒÔÏ > ëÉÅ× >
attached mail follows:
B.C. Lance wrote: > not from meta refresh. but javascript could do that. set a timeout that > will fire the submit event after 2 seconds. that will work. > > b.c. lance >
ðÒÉ×ÅÔ!
I already have that and it works fine. The problem is when jscript is not working (or missing). I was trying to build up some panic tree in case jscript fails.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
you might wanna fire that javascript using onload from the body tag. that kinda assure the page is loaded successfully before the event takes off.
Alberto Serra wrote: > I already have that and it works fine. The problem is when jscript is > not working (or missing). I was trying to build up some panic tree in > case jscript fails. > > ÐÏËÁ > áÌØÂÅÒÔÏ > ëÉÅ× > > > >
attached mail follows:
B.C. Lance wrote: > you might wanna fire that javascript using onload from the body tag. > that kinda assure the page is loaded successfully before the event takes > off.
ðÒÉ×ÅÔ!
It is there already. My problem is to do it something that will save my *ss in case jscript is *NOT* there. So it must be a no thrills HTML solution that will run anyway, no matter how poor in resources the browser is.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
hm... how about sticking couple of iframes that will load the piece of javascript and have each of the javascript in the iframe firing at different time? i suppose at least 1 copy of javascript will be there to do the intended work.
Alberto Serra wrote: > It is there already. My problem is to do it something that will save my > *ss in case jscript is *NOT* there. So it must be a no thrills HTML > solution that will run anyway, no matter how poor in resources the > browser is. > > ÐÏËÁ > áÌØÂÅÒÔÏ > ëÉÅ× > >
attached mail follows:
ðÒÉ×ÅÔ!
Sorry, I forgot writing a intelligible subject on previous posting :( So I repeat.
Probably a stupid question. Is there anyway to force POSTing a form from the refresh META?
<META HTTP-EQUIV="Refresh" CONTENT="2;URL=someURL/somescript.php">
IMHO that is NOT possible, but maybe I am wrong.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
sorry to barge in. but the weakest link ain't in ssl. doesn't really matter how secure vs insecure it is. you can come up with the most secure technology in the whole world that no one can break into. the weakest link lies on the user/customer themselves.
you just need a trojan horse in their computer and there goes the neighbourhood. they can by all means send their credit card information over to amazon.com. but this piece of information will still be open to the person who plant the horse in the machine.
so i suppose the debate over here should really be: is ecommerce safe? and not: http vs https
just my 2 cents b.c. lance
attached mail follows:
ðÒÉ×ÅÔ!
I detach this from current thread as it has nothing to do with it :)
now: ðÒÉ×ÅÔ! means "hello" (pronounce "preevjet", accent goes on je) ÐÏËÁ means "bye" (pronounce "paka" accent on last a)
The rest is just my name (Alberto, I am italian as of original nationality) and the name of the place I am, that is, Kiev, the capital of Ukraine :)
I got SOOO annoyed by charset trouble in the last week that I decided to do something to enhance people's consciousness on the matter, by mixing alphabeths and languages in all of my mails.
Yes, it IS a pointless effort made by a powerless dwarf. :)
ðÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
attached mail follows:
The newbie is still having troubles heh. Maybe some kind soul can tell me what im doing wrong this time. This is the code for a page I am working on. When I try to bring up the page in a browser, I just get a white page, instead of having the HTML display. Anyone able to tell me why?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html> <head> <title>Login Page</title> </head> <?php $dbhost = "127.0.0.1"; $dbuser = "root"; $db = "LoginInfo";
$LoginDB=mysql_connect($dbhost, $dbuser, $dbpass);
if (! $LoginDB) {
print "<p>Unable to connect to the database server at this time.</p>";
exit();
} else {
mysql_select_db("GameDB",$LoginDB);
if (! mysql_select_db("GameDB") )
print "<p>Unable to locate the Game Database.</p>";
exit();
}
?>
<style type="text/css">
body { color: white; background: black; }
</style>
<p align="Center"><img src="Banner.png" width="666" height="103"
alt="D&D Resource Page" border="0">"</p>
<br><br><br><br>
<form name="Login" method="Post" action="<?echo $PHP_SELF?>">
<p align="Center">
Login: <input type="text" name="User Name">
Password: <input type="password" name="Password">
<input type="submit" name="Submit" value="Submit"
</p>
</form>
<?php } ?>
</html>
attached mail follows:
ðÒÉ×ÅÔ!
B.C. Lance wrote: > hm... how about sticking couple of iframes that will load the piece of > javascript and have each of the javascript in the iframe firing at > different time? i suppose at least 1 copy of javascript will be there to > do the intended work.
I realize I was being obscure :) BTW, the solution was obvious, I'll better explain what I am doing.
This is a "loader" utility that is put instead of the index.php script to configure a session by understanding what kind of client is calling, so it's very generical software that is shared among many a project.
In short, what index.php does is: 1) accept command line parameters (and the docs referrer) that are received and stock them somewhere for later use 2) sets a test cookie 3) generate a page that shows "loading..."
javascript in this page verifies user configuration (screen, java enabled, platform etc) and stuffs this data into a hidden form then sends it back to index.html where data will be used to understand whether we can rely on jscript and cookies within this session.
*The problem was here*. What if this second step fails? easy, I just leave the META as is and stock previous data on a session during the first execution of index.php
At this point index.php knows all it needs to fill in cionfiguration data and it just includes the real home page. From now on we will be able to tailor channelling (that is, cookies or not, jscript or not) without reasonable doubts. Yes, the user *may* change it's configuration during the session, but this is very low percentage of cases and we can live with it.
Well, that's the most general part of it. But at least it's clearer.
ÐÏËÁ áÌØÂÅÒÔÏ ëÉÅ×
--
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]