php-general Digest 31 May 2010 21:06:31 -0000 Issue 6775
Topics (messages 305670 through 305676):
Re: NetBeans Question
305670 by: Jan G.B.
Re: Credit Card encryption
305671 by: Phpster
305674 by: tedd
305676 by: tedd
Re: MVC logic
305672 by: Michiel Sikma
Re: Select Values Didn't Get Passed in From Two Different Forms
305673 by: tedd
305675 by: Alice Wei
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi there.
I'm also a User of the Netbeans IDE and I can tell you the following:
- Netbeans is the only IDE who can load very large PHP scripts (f.e.
>1mb PHP Script with a multiple of 10thousands of lines) with syntax
highlighting and SUPERB code completion. It works with include files,
you can adjust RAM settings, you can work with files opened via ssh,
Subersion integration is absolutley loveley, you can connect to a
DB-Server with it to have the Schema and so on in your IDE, the
Debugging feature works like a charm and it's simply much better than
the following IDEs:
- Zend Framework
- Komodo Edit/ Komodo IDE
- Eclipse
- Kdevelop (heh - just kidding, mentioning this one)
I Use it on Linux 64 bit and it simply rocks.
@tedd: I'd just do what's obvious: Use a versioning system like
Subversion. It can work via ssh, so there's no need to open a port for
an extra daemon on any server.
Further questions may be addresses to this list, I'd say. You'll have
a more chances for an answer. ;)
Regards
2010/5/31 Mario Lacunza <mlacu...@gmail.com>:
> Hello,
>
> what about the Netbeans ram eating?
>
> Mario
>
> On 31/05/10 02:03, Dušan Novaković wrote:
>>
>> Hi, I've been using NetBeans for some time and I found that there are
>> some issues like for Web applications if you write html tag
>> incorrectlly, you wont be informed about that, for stand alone
>> applications in Java there were also some stupid errors, etc. So, I
>> strongly suggest to check out Eclipse(http://www.eclipse.org/)! You
>> can easily download Eclipse for PHP on Windows, Linux and MAC, and the
>> best part is that you can also easily find and add different plugins
>> like SVN, JS, etc. Just check it out... ;-)
>>
>> Regards,
>> Dusan
>>
>> On Mon, May 31, 2010 at 4:13 AM, Mark Kelly<p...@wastedtimes.net> wrote:
>>
>>>
>>> Hi.
>>>
>>> On Monday 31 May 2010 at 02:50 Ashley Sheridan wrote:
>>>
>>>>
>>>> Yeah, like I mentioned earlier, Dreamweaver is known for having issues
>>>> with include files, can be slow when working on large projects with lots
>>>> of files, and is only available for Mac and Windows, which limits it
>>>> somewhat.
>>>>
>>>
>>> Indeed. I can't stand the thing myself - I was just being polite :)
>>>
>>> I use netbeans on Linux and Windows, so its cross-platform nature is
>>> quite
>>> important to me. I also appreciate the Subversion integration, which is
>>> very
>>> nicely done.
>>>
>>> Tedd: I'm no expert, but I'll chime in if I have any answers for you.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>>
>>
>>
>>
>
> --
>
> Saludos / Best regards
>
> Mario Lacunza
> Email:: mlacu...@gmail.com
> Personal Website:: http://lacunza.biz/
> Hosting:: http://mlv-host.com/
> Google Talk: mlacunzav Skype: mlacunzav
> MSN: mlacun...@hotmail.com Y! messenger: mlacunzav
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On May 31, 2010, at 1:24 AM, Paul M Foster <pa...@quillandmouse.com>
wrote:
On Sun, May 30, 2010 at 03:30:28PM -0400, Phpster wrote:
<snip>
I work with some of the largest retailers in north America if not the
world, and I can confirm that the security measures taken to enforce
pci compliance are not something lightly undertaken.
If those entities choose to store the cc#s then they do the
following:
1. Store the encrypted values on servers that are NOT web facing
Absolutely! If I were trying to do this on a web server, I *would*
use a
payment gateway. There's no way I could secure it adequately
otherwise.
2. Use ridiculously long encryption keys ( well into the 1000s of
characters)
3. They also create a representative value that exists outside the
system that has to allow some basis of data mining.
Really as mentioned you don't want to do this. Especially if you have
no control over the servers.
I have complete control over the server this information is stored on,
including physical control. It is behind a NATed firewall and only
accessible to certain machines on my internal network. The only
personnel with access to the server are myself and my wife.
To be clear, we process credit cards MOTO, meaning we have no physical
access to the cards themselves. We use a small terminal which dials up
our payment processor to get approvals. The problem is that virtually
all of our credit card business is with the same customers and
recurring. So it's not feasible to call them every month or several
times per job to ask for a credit card number. This would aggravate my
customers. So I have to store the information one way or another, on
3x5
cards, in the computer or some way.
And it appears from all the replies that there is no other way to do
it
than to have a separate key or password for accessing just these
credit
card numbers, and every time they must be accessed, the user must
provide this key, which would be in addition to the usual password for
that user.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
It sounds like a lot of the activity is subscription based, is that
correct? Paypal does support that.
I would suggest looking thru the oci guidelines if you haven't done so
already. The point there are essential requirements and should be
enough for you to judge if you can be compliant with the rules.
Pci is a total PITA, and the fines are not worth it if you can't meet
the requirements.
Bastien
Sent from my iPod
--- End Message ---
--- Begin Message ---
At 1:38 AM -0400 5/31/10, Paul M Foster wrote:
On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote:
> Besides, most credit card processing agencies even require that you
use the customer's data (cc number, expiry date and CCS) to make the
sale and then immediately dispose of it afterwards, usually within 24
hours under a signed agreement. Holding that information for more
than 24 hours can be a criminal offense regardless of what type of
hashing you use.
Not true. It depends on the type of merchant and the situation.
*blink*
"Not true" and "It depends" are conflicts in logic.
Either what I said is "true" or it isn't -- and if what I said is
"true" for some (as it is and I can prove it) then what I said is
indeed "true".
I'm curious, why say it's not "true" and then follow with "it
depends"? It appears to me that you have your mind made-up and don't
care to listen to our experiences and recommendations.
That's Okay, but I'm simply telling you what I KNOW to be true. You
may either accept what I have to say, or reject it, but to reply that
what I say is "Not true" is somewhat offensive and confrontational. I
hope you didn't mean it that way. :-)
The PCI
validation process allows for storage of all data except the 3-4 digit
validation number. What I'm asked for at transaction time is the CC
number, expiration date, digits for the billing address, and the billing
zip code. And I can get the address and zip digits completely wrong and
still have the transaction go through.
Party true.
What data are used in credit card transactions are the: name of the
card holder, credit card number, expiration date, CCV number, and zip
code. I have not dealt with any credit card processors that require
the billing address -- they just use the zip code. Additionally, it
is up to the client to determine the level of security they want.
They *can* require that *all* information be correct before accepting
a sale.
The downside of not requiring *all* the data to be correct is that
the rate the credit processor charges for the transaction rises.
Simply and logically put, if you don't get all the information
correct, then there is risk and that risk is passed on to the client
via an elevated charge for processing -- look it up.
The up-side of getting only the minimal data is getting a sale under
a higher risk/rate -- that's the clients choice and they usually
choose it.
We've been doing it this way for 14 years and using the type of service
you suggest would be expensive and impractical. Only in the last two
years has PCI become more stringent in their requirements. And
consequently, I'm having to re-evaluate how we store this particular
information. Otherwise, our physical and other security is more than
adequate. Yes, of course, if you have a machine gun or you're Kevin
Mitnick, or you have a network of 20,000 bots pounding on my router,
you're coming in anyway. Again, this is about *reasonable* security.
You asked for opinions -- do what you want. :-)
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 12:36 PM -0400 5/31/10, I wrote:
That's Okay, but I'm simply telling you what I KNOW to be true. You
may either accept what I have to say, or reject it, but to reply
that what I say is "Not true" is somewhat offensive and
confrontational. I hope you didn't mean it that way. :-)
My apologies for taking what you said as I did and my reply -- it was
wrong of me. I am sure you didn't mean anything offensive.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 29 May 2010 20:39, Tanel Tammik <keevit...@gmail.com> wrote:
> Hello,
>
> i'm trying to break this thing down for my self. i made little application
> for that. could someone please take a look and let me know if what i wrote
> resembles MVC inviroment or not.
>
>
It's crucial that your application parses the location (e.g.
http://site.com/my/url-title/) and then loads a controller. As it is right
now, your index.php is hardcoded to load the "messages" controller. That
shouldn't happen.
You should refactor your application so that the index.php does nothing
except load the config, parse the request and then load the appropriate
controller. And you should move the "templates" directory to the
"application" directory (and maybe call it views for clarity). Everything
that the user writes should be in one directory so that he can update the
underlying system without deleting or overwriting files that he made.
Regards,
Michiel
--- End Message ---
--- Begin Message ---
At 7:23 PM -0400 5/30/10, Alice Wei wrote:
Tedd,
Looks like I finally found the answer to my question, and the key
is the term, dependent drop down menu. There is an example that I
found here,
http://www.huanix.com/files/dependent_select/dependent_select.txt,
and after editing everything, looks like what I want is not so far
to reach. As I am writing now, I got the code I desired to work
after studying what went on in the code from the above link.
Thanks for your help, and looks like I solved the problem, I may be
able to close the thread now.
Alice
Alice:
An interesting solution.
I tested it here:
http://php1.net/a/ajax-select-db
The database needs a little work -- I wasn't aware that Virginia was
a State in Germany. :-)
It also needs a little work when someone changes an intermediate
selection to null the ones further down the chain -- it only goes one
deep.
The control also uses GET when I think POST would work better -- at
least it would hide the inner-workings of the control from the user.
However, if that was what you were looking for then great.
Good luck and thread closed.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
> Date: Mon, 31 May 2010 11:56:38 -0400
> To: php-gene...@lists.php.net; aj...@alumni.iu.edu
> From: tedd.sperl...@gmail.com
> Subject: RE: [PHP] Select Values Didn't Get Passed in From Two Different
> Forms
>
> At 7:23 PM -0400 5/30/10, Alice Wei wrote:
> >Tedd,
> >
> > Looks like I finally found the answer to my question, and the key
> >is the term, dependent drop down menu. There is an example that I
> >found here,
> >http://www.huanix.com/files/dependent_select/dependent_select.txt,
> >and after editing everything, looks like what I want is not so far
> >to reach. As I am writing now, I got the code I desired to work
> >after studying what went on in the code from the above link.
> >
> >Thanks for your help, and looks like I solved the problem, I may be
> >able to close the thread now.
> >
> >Alice
>
>
> Alice:
>
> An interesting solution.
>
> I tested it here:
>
> http://php1.net/a/ajax-select-db
>
> The database needs a little work -- I wasn't aware that Virginia was
> a State in Germany. :-)
>
> It also needs a little work when someone changes an intermediate
> selection to null the ones further down the chain -- it only goes one
> deep.
>
> The control also uses GET when I think POST would work better -- at
> least it would hide the inner-workings of the control from the user.
>
> However, if that was what you were looking for then great.
About the get and post, yes, I did change that to post in my sample, but thanks
for pointing it out.
Alice
>
> Good luck and thread closed.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
--- End Message ---
