Re: [PHP] keeping credit card info in session

[Jochem Maas]

[EMAIL PROTECTED] wrote:
> Thanks a lot every one. These are great replies.
> 
> I guess I should have explained a bit more about what I'm doing.
> 
> first of all, this is not my site, it's for a client of mine.

probably irrelevant from a legal pooint of view.
> 
> second, I did suggest using a paypal API or a paid site to take care of this, 
> but my client said no. She has a credit card processing account and how she 
> works with it right now, is that interested users email her, she calls them, 
> gets their credit card info and charges their card manually without the card 
> present.
> 
> so, this is not really my problem, it's what she's been doing before and 
> wants 
> to continue doing. All she asked me to do is that as part of the form that 
> people send their requests through, now she wants their credit card info as 
> well. So that she doesn't have to call them.

tell her 'PAYMENT PROVIDER OR BUST'. :-)

> 
> And the reason I'm keeping cc info in the session for a few steps, is to take 
> them to confirmation page, and then the reciept page. and after wards, I want 
> to keep it in there untill the client logs in to the admin page and sees new 
> requests, charges them and then deletes them for ever.

you think you want this, but you don't.

> 
> So now I've got two different responses, some people say do it, but use 
> encryption/decryption methods, and some people say don't do it. 

does your client have a million dollar budget (including cash surplus to handle
lawsuits and fines from banks or CC companies) to design and administer
the security of the complete software stack that the CC will be handled by
and stored on?

no I didn't think so, ergo don't go down this route  anyone tell you
its a good idea (regardless of encryption) needs their head examined.

> But if I don't 
> do it, that means I tell my client that I can't do it and I lose the job.
> 

good, dont take the job. some one else will take the blame when things go
seriously wrong (assuming she can find anyone to take the job.) and leaves
you to doa project that won't make you bankrupt.

> 
> 
> Thanks again,
> Siavash
> 
> 
> 
> 
> Quoting Travis Doherty <[EMAIL PROTECTED]>:
> 
>> Jochem Maas wrote:
>>
>>> unless you are a payment gateway or a bank don't touch credit card numbers.
>>> there are plenty of threads in the archive of this list that give good
>> reasons
>>> not to e.g. being sued out of existence.
>>>  
>>>
>> 100% agreed.  Never touch credit card numbers.  You can't just take
>> credit card numbers and manually process them in 'card not present'
>> transactions (or MOTO in more archaic terms.)  You need a merchant
>> account that allows for this -- usually at a higher discount rate. 
>> Check the merchant agreement.
>>
>> Your client should get an account like this, or better yet, provide you
>> with the instructions on how to integrate his site with the payment
>> providers so that you never have to worry about credit cards.
>>
>> As an additional note... Maybe your SSL cert secures the numbers from
>> the client to the server, and just maybe your PHP scripts have no
>> security flaws in them, but you must remember the server itself and
>> everything else outside of PHP.  What if someone found a flaw in the FTP
>> server for example, or the mail server even, and used that to get the CC
>> info.   I would hate to be explaining to a list of 1000 clients that I
>> was responsible for their card numbers being stolen.
>>
>> Travis Doherty
>>
> 

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

Re: [PHP] Design Dilemma - Database Data Abstraction

[Lester Caine]

Martin Alterisio wrote:

I have a dilemma on a design where I humbly ask your help. I'm working on
the model part of a web application (not to be understood in the "web2.0"
way, but in a more general way, where anything mounted on HTTP is a web
application) done in PHP5 following the MVC design pattern. But the strong
point is that the result must be those-who-never-RTFM-proof. But that's not
my dilemma, I only mention this so that no RoR concept or similar is thrown
into the table, that is, NO ActiveRecord.

The solution I presented is to access, and act upon, a database as if they
were PHP arrays, meaning that a table is presented as an array of records.
Here comes my dilemma. But first let me explain a bit about the scenario so
far:


I snip there - too much detail without defining the problem ;)

Database Data Abstraction normally refers to using a common internal structure 
which can be loaded from a range of database engines. It sounds as if you have 
no requirement to 'Abstract' the database, only to come up with a persistent 
object layer under a single database engine?


You have indicated that you are looking for a multi-user system, and so the 
raw data must be in the database, but as you have seen, the flexibility 
afforded by any database engine is difficult to duplicate. The thing to 
remember is that you should ONLY be reading the data you need for the current 
user, and so your persistent objects do not need to be as complex as you seem 
to be looking for. It is always faster to ask the database for an answer than 
to copy everything to PHP in order to work with it. With any decent database 
you can provide views of the data in a suitable format for the arrays you need 
display on the user interface.


I tried to find something suitable to point you at, but it's difficult
http://www.appelsiini.net/~tuupola/php/DB_DataContainer/
Is probably in line with your current outline?

--
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php

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

[PHP] DOM and XSLTProcessor

[Buesching, Logan J]

Greetings,

 

I apologize if this is a little long, but I am trying to put as much
information as I have done in this first post.  I am running PHP 5 and
attempting to use DOM to create data to show on a webpage and using
XSLTProcessor with an XSLT sheet to output it into XHTML.  Everything is
pretty fine an dandy until I wish to print raw text, such as xdebug and
var_dump.

 

My knowledge of DOM and XSLTProcessor is about a 5/10, such that I know
most basics, but not the more advanced things.  Whenever I try to add
data using createTextNode, it is always escaped, such that if I do
something, when shown to the screen, it shows
 etc...  

 

Here is the general outline:

 

createElement("root");

$wantedCode=$doc->createTextNode("Something");

$root->appendChild($wantedCode);

$doc->appendChild($root);

$proc=new XSLTProcessor;

$proc->importStylesheet(DOMDocument::load("test.xslt"));

echo $proc->transformToXML($doc);

?>

 

SomeSheet is something like:







 

The expected output that I would like to get is:

Something

(This would just bold my text, not literally see the  tags).

 

The actual output is:

Something

(This outputs the  tags to the end user, which is what I do not
want).

 

I checked the manual at:
http://us3.php.net/manual/en/function.dom-domdocument-createtextnode.php
.  A user comment suggested to use CDATA nodes, so I attempted to change
my code to the following:

 

createElement("root");

//note the change right here

$wantedCode=$doc->createCDATASection("Something");

$root->appendChild($wantedCode);

$doc->appendChild($root);

$proc=new XSLTProcessor;

$proc->importStylesheet(DOMDocument::load("test.xslt"));

echo $proc->transformToXML($doc);

 

?>

 

But this was of no success; it just had the same output.

 

Is there anyone that is able to help me out here?

 

Thanks,

Logan