[PHP] More thoughts about PHP: Taglibs
It seems to me that one of the problems with PHP is that you have to include code in your HTML pages. Even with the cleanest design, you end up with HTML that looks like this: html Hello, ?php showusername(); ?. Your last login was ?php showlastlogin(); ?.p /html This is ok, but it seems to me that java taglibs provide a more elegant way to do the same things: html Hello, showusername/. Your last login was showlastlogin/.p /html This lets the backend stuff be completely separated from the html design part of things. What do people think of this? I'm just now learning JSP so I'm thinking about the differences between PHP and JSP. In general, both are powerful ways of creating dynamic websites, but they have different characteristics and are better for different things. I'm learning java but I will continue to use both, depending on the task. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Using mcrypt in PHP
There seems to be no reliable information in the manual about how to do this. I'm trying to use mcrypt 2.4 with php4.06, which should be a compatible combination. So far, I have gotten it to work like this: $cypher = MCRYPT_RIJNDAEL_128; $encrypted = mcrypt_encrypt($cypher, $key, $plaintext, MCRYPT_MODE_ECB); $decrypted = mcrypt_decrypt($cypher, $key, $encrypted, MCRYPT_MODE_ECB); However, when I do this, I get an error saying: Warning: attempt to use an empty IV, which is NOT recommend in So I tried to do the same thing with an IV: $iv = mcrypt_create_iv(mcrypt_get_iv_size($cypher, MCRYPT_MODE_ECB), MCRYPT_RANDOM); and then added this $iv as an argument to encrypt and decrypt. At this point, it doesn't work, because the iv is different in the encrypt and decrypt functions, because it is randonly generated. Is it true that I need the same iv to encrypt as to decrypt? I'm just not understanding how to use this. All I want to do is to encrypt stuff and then decrypt it, using a key, right? It used to work. Thanks. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] SSL encryption type in PHP?
You can tell it using the variables from the server. Using Apache you can access the variables specs at: http://www.apache-ssl.org/docs.html With Apache SSL is SSL_CIPHER returns the variable about SSL/TLS ciphersuite. Do you know how I would access that variable from PHP? Is that possible? I know how to configure apache to reject conections based on encryption settings, but instead of rejecting them, I would like to accept them but warn the user: You should upgrade your browser. Is this possible? Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] SSL encryption type in PHP?
Is there a function in PHP which can tell me the encryption strength being used by the browser? I want to be able to put a little message on the page saying, You are using strong encryption or Warning: you should upgrade your browser to one which supports 128bit crypto. Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Making graphs from within PHP?
I have a PHP application, and I need to display some dynamic data as a simple line graph (a gif or png). Is there a simple way to do this? Maybe something I can compile in to PHP? Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Credit card number checker?
I know that credit cards have standard formats: There's a standard number of digits, and whether the card is Visa, MC, Amex, etc is encoded in the number, and there is some kind of checksum, and I think the expiration is also encoded in the number. All of this is obvious stuff that anyone designing such a system would do. I'm wondering if anyone can refer me to a site that describes what this format is, so I can write some PHP code that will check to see if a credit card number format is correct. I don't even want to try to run the card through my merchant account if the format is obviously wrong. I assume that banks check the rejection rate on their merchant accounts, and too many bogus cards would not look good. I did a quick search on the web, and there are a vast number of hacker credit card number generators, but that isn't exactly what I'm looking for. Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Updated credit card number checker
Some helpful people posted a PHP credit card number verify on this
list. It would verify Visa and MC cards. I made some modifications
to it so that it would verify other types of cards, and return the
type of card it found. That way, you could have something like this
on your webpage:
input type=radio name=cctype value=Visa Visabr
input type=radio name=cctype value=MasterCard MasterCardbr
input type=radio name=cctype value=AmericanExpress American
Expressbr
input type=radio name=cctype value=DinersClub Diners Club /
CarteBlanchebr
input type=radio name=cctype value=Discover Discoverbr
input type=radio name=cctype value=EnRoute EnRoutebr
input type=radio name=cctype value=JCB JCBbr
and then you could have a call like this:
if(ccverify($Number) != $cctype) { // there's an error
which would catch some user errors
Anyway, here's the revised script:
?
#
# Credit Card Validation Solution, version 3.5 PHP Edition
# 25 May 2000
#
# COPYRIGHT NOTICE:
# a) This code is property of The Analysis and Solutions Company.
# b) It is being distributed free of charge and on an as is basis.
# c) Use of this code, or any part thereof, is contingent upon leaving
# this copyright notice, name and address information in tact.
# d) Written permission must be obtained from us before this code, or any
# part thereof, is sold or used in a product which is sold.
# e) By using this code, you accept full responsibility for its use
# and will not hold the Analysis and Solutions Company, its employees
# or officers liable for damages of any sort.
# f) This code is not to be used for illegal purposes.
# g) Please email us any revisions made to this code.
#
# Copyright 2000 http://www.AnalysisAndSolutions.com/code/
# The Analysis and Solutions Company [EMAIL PROTECTED]
#
#
# DESCRIPTION:
# Credit Card Validation Solution uses a four step process to ensure
# credit card numbers are keyed in correctly. This procedure accurately
# checks cards from American Express, Australian BankCard, Carte Blache,
# Diners Club, Discover/Novus, JCB, MasterCard and Visa.
#
# CAUTION:
# CCVS uses exact number ranges as part of the validation process. These
# ranges are current as of 20 October 1999. If presently undefined ranges
# come into use in the future, this program will improperly deject card
# numbers in such ranges, rendering an error message entitled Potential
# Card Type Discrepancy. If this happens while entering a card type
# you KNOW are valid, please contact us so we can update the ranges.
#
# POTENTIAL CUSTOMIZATIONS:
# * If you don't accept some of these card types, edit Step 2, using pound
# signs # to comment out the elseif, $CardName and $ShouldLength
# lines in question.
# * Additional card types can be added by inserting new elseif,
# $CardName and $ShouldLength lines in Step 2.
# * The three functions here can be called by other PHP documents to check
# any number.
#
# CREDITS:
# We learned of the Mod 10 Algorithm in some Perl code, entitled
# The Validator, available on Matt's Script Archive,
# http://worldwidemart.com/scripts/readme/ccver.shtml. That code was
# written by David Paris, who based it on material Melvyn Myers reposted
# from an unknown author. Paris credits Aries Solis for tracking down the
# data underlying the algorithm. At the same time, our code bears no
# resemblance to its predecessors. CCValidationSolution was first written
# for Visual Basic, on which Allen Browne and Rico Zschau assisted.
# Neil Fraser helped prune down the OnlyNumericSolution() for Perl.
// modified by Dr. Evil to handle a bunch of other card types
function getcctype($Number) {
# 1) Get rid of spaces and non-numeric characters.
$Number = substr(ereg_replace( [^0-9], , $Number), 0, 19);
//
// for testing purposes, allow this number in
// turn it off before deploying code
if($Number == ) { return Test; }
# 2) Do the first four digits fit within proper ranges?
# If so, who's the card issuer and how long should the number be?
$NumberLeft = substr($Number, 0, 4);
$NumberLength = strlen($Number);
$firstdig = substr($Number, 0, 1);
$seconddig = substr($Number, 1, 1);
if ($NumberLeft = 4000 and $NumberLeft = 4999) {
$CardName = Visa;
if ($NumberLength == 16) {
$ShouldLength = 16;
} else {
$ShouldLength = 13;
}
} elseif ($NumberLeft = 5100 and $NumberLeft = 5599) {
$CardName = MasterCard;
$ShouldLength = 16;
} elseif((($firstdig . $seconddig) == 34) ||
(($firstdig . $seconddig) == 37)) {
$CardName = AmericanExpress;
$ShouldLength = 15;
} elseif(($firstdig == 3)
(($seconddig == 0) || ($seconddig == 6
[PHP] Strong typing?
PHP is a great language. It makes it fast and easy to create web pages. However, one feature which is critical for doing rock-solid stable websites is strong typing. The reason for this is that you're dealing with untrusted user input. Strong typing helps because if you are expecting an INT, and the user gave you something else, and you made a mistake in your input checking, the program will fail when you attempt to assign the value to the strongly-type INT variable. This is a good thing when you are dealing with money, or other contexts where you need very solid code. First, is there a plan to introduce a strong typing option, like perl's strict mode? Second, is there a way to get something equivalent to strong typing using the class system? Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Strong typing?
U... you could write a fuction like
function CheckInputAgainstRE( $val, $re )
{
if ( ! ereg( $re, $val ) )
{
( ... some kind of code that writes out an error message and dies
... )
}
return $val;
}
That's what I've done. I have a huge file full of all kinds of data
checking functions. However, what if I forget to call one of them, or
one doesn't work the way I expect it to? Strong typing means that the
script will just die, instead of possibly passing the wrong values
into the SQL query. This is exactly the same reason why perl has a
strict mode. Sure you could write a lot of input checking functions
(which you will have to do no matter what) but you should have
constraints built into your data structures.
It's just like with SQL: if you know that a certain value in a table
has a certain constraint (a withdrawal must always be greater than
zero) then you should put that constraint into your table definition,
so that an error somewhere else will be limited in its effects.
If you're doing financial stuff, or anything else that requires
bullet-proof security and reliability, strong typing is essential, in
addition to checking all the user input.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] The need for strong typing...
As you know, gases such as oxygen and acetylene are distributed to
welders in pressurized containers. As you can guess, it is very
important to put the right stuff in the right container. Let's say
you have a container of acetylene, and you accidentally top it up with
some pure oxygen. This is likely to be a life-altering exerpience,
and not in the New Age chanting-in-a-sweat-lodge sense if you know
what I mean.
The naive solution to this problem is to put a big sign up that says,
Warning: be very careful about which gas you put into which tank.
I'm sure that was the first approach that was tried when pressurized
tanks for welding were first developed. After a few people died by
putting the O2 in the C2H2 tank, someone came up with a brilliant
solution: Let's put reverse threads on the O2 tank attachments. That
way, the tank, and all the hoses and connectors that go with it, can
never be attached to a C2H2 tank, because of a physical contraint in
the connections themselves. O2 uses left-hand twist and C2H2 uses
right-hand twist, and so the two will never meet. No matter how
asleep, negligent, or incompetent the filling operator is, he'll never
end up with O2 in the C2H2 tank. Even the sharpest, most cautious
tank filler will eventually make a mistake if he does it enough times,
but never if the threads are reversed.
Data structure contraints are exactly the same idea. In my DB I have
a table for payments. Every time Alice pays Bob, a row gets added
to this table, with one of the columns being amount of transfer. Of
course, on the PHP side, I put in a check:
if($amount = 0) { // error condition }
but, in addition to that, in the database itself, I have
CONSTRAINT amount 0
built into the table definition. That way, no matter what goes wrong
on the PHP side, Bob will never be able to say, Pay alice -$1mil,
and find his account $1mil richer. The value is checked (several
times) in the PHP side, but the right behavior is built into the data
structure (table) itself.
Strong typing is a sort of constraint. Just like I don't want to be
using O2 when I think I'm using C2H2, I would like to be sure that
I've got an INT and not a STRING when I expect an INT. Saying write
a bunch of functions to check user input, and don't make any mistakes
is just like putting up a sign that says, Be very careful to not put
O2 in the C2H2 tank. Yeah, if I were perfect, that would be enough,
but in the real world, when you're dealing with serious things like
exploding tanks and money, you want some built-in constraints in the
system. You want correctness to be enforced at several different,
independent layers.
This same design principle applies in many different realms: my
motorcycle has completely independent front and rear brakes, so even
if one system fails entirely, I can still stop. My Glock has three
independent safety systems (trigger block, firing pin block,
decocking) which must each be operational for it to fire. It's just
good design to have redundant constraints to achieve high reliability
and safety. Strong typing is one of those contraints.
This doesn't mean that PHP should be changed to allow strong typing.
It may mean though that PHP isn't the right language for rigorous
applications like financial transactions.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] The need for strong typing...
The one problem with all your musings is that there is no such thing as an
integer when it comes to transferring data over http. Everything comes as
a string. What is done with these strings when they get to the
application is what matters. It's not like there is an HTML form element
like input type=integer or input type=float. All you have is input
type=text when it comes to users entering data and passing it to you. I
fail to see how strong typing helps you here at all. You are going to
have to apply some sort of user-space rule once you receive the data. And
that is quite easy to do with PHP.
Right, obviously. The only data type in http is the string. However,
there is obviously some value in being able to say:
function pay(fromaccount int, toaccount int, amount int, memo
varchar(100)) { //
instead of:
function pay(fromaccount, toaccount, amount, memo) { //
In the former case, even if there was a mistake in checking user
input, at least the script will die instead of trying to do some
operation on some impossible data type. That's a good thing.
Obviously, all user input must be taken from string type to other
types, but internal functions should be constrained. It's just
another level of checking. It's exactly the same reason why databases
allow you to put constraints into table definitions. Sure, you should
check that the value is positive when you do the INSERT, but you
should also put a constraint into the table. Lots of things go
wrong.
Also obviously, this capability isn't needed for most of what PHP is
used for, and so maybe it doesn't belong in PHP, and maybe those of us
who are writing more sensitive aps should look into other things. Any
sugestions?
I don't want people to think that I'm bashing PHP. I'm not. I love
it. I could never go back to perl or anything else. It's just that
I'm working on this one particular financial application, and I'm
paranoid that something will slip through somewhere, and I would feel
more comfortable if I could define variables that have built-in
constraints. Can I use classes to do this?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] The need for strong typing...
I was going to write a whole diatribe, venting rage, trying to prove you wrong etc, etc... and then I got to the last paragraph and realised we probably actually agreed: Yes, I think so too. Different languages for different things. Even COBOL has a valid reason for existing. In fact, most of my app is written in pl/pgsql, which is a lot like COBOL in that it has very limited capabilities and a very clear syntax and strong typing. It's hard to make mistakes in it. This doesn't mean that PHP should be changed to allow strong typing. It may mean though that PHP isn't the right language for rigorous applications like financial transactions. The main problem with the Oxy-Acetylene analogy is that there is very little that anyone does with PHP that could even vaguely be considered life threatening - in most cases the worst case scenario is that if something goes wrong, someone will get a bit annoyed. Even with financial transactions - an error going wrong there is really BAD, but generally it CAN be tracked down and fixed, and no one is going to die as a result. That's true for old-style financial apps, where a check can be bounced, transactions reversed, etc, but in a modern real-time gross settlement system, errors can be very expensive, and hackers are always on the prowl. Spending $100k to make sure the code is rock-solid is probably cheaper than letting some errors or uncertainties creep through. Anyway - you talked about having a series of hurdles for things to get past. So, strong typing has been removed as a hurdle - fine, lets just add in a few more like rigorous testing and rigorous code reviews and careful design and rigorous design reviews. Good point. Another point is that this software will not suddenly be used for billion-dollar payments. It will start with a small user base and small values, where mistakes won't be fatal, and then it will grow, and as it grows, there will be more code reviews, design reviews, etc. The MOST mission critical software ever written is, I think, the software that controls the space shuttle as it gets launched. Once the final ignition sequence goes off, nothing can stop it and the only thing controlling it is the software. That graceful takeoff and roll it does on takeoff would be impossible for a human to control. That software is as close to bug free as you will ever get. It is also incredibly expensive because EVERY change is reviewed, analysed, studied and tested incredibly thoroughly to review it's impact and to make sure it will have no roll on effects. Interesting story. Fortunately, financial transactions are actually simpler than shuttle launches. Really, the whole thing consists of: 1. Is the user authorized to make this transaction? 2. Does the user have sufficient funds/credit to make the transaction? 3. Is the recipient authorized to receive the transaction? 4. Lock the sender's account. 5. Check the funds/credit again. 6. Make the transaction. 7. Unlock and inform the user. It's simple, but mistakes are expensive. I will look into JSP. Even on the same website, we could have two different languages: Maybe we'll use JSP for the transaction stuff, and PHP for customer support pages, where things are less critical. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
