SaranacLake

Okay, this is a head scratcher for me... About 10-15 years ago, there was this framework that seemed to be pretty popular in the LAMP work for quickly building websites. (I think it was written in PHP.) The thing I recall about it was that it you could create your own markup tags to markup up fields using curly brackets { }. I wish I could be more specific but this is all that is coming to mind. Any clues of what I might be thinking about?

I built most of my site a loooong time ago, and have forgotten a lot. Can you please refresh my memory of how a sessionID would end up in the URL? My site doesn't use cookies, and everything is done using the sessionID. As I recall, I guess the only cookie I use is to store the sessionID which I believe was the safest at the time I did things. But maybe things have changed and I certainly want things to be *secure* to protect my customers! Yeah, last month I think I came up with a fairly simple SKU that is under 8 characters - a combination of letters and characters like eb501 for eBook 501. So to tie this together... I can build a gallery of free eBooks using "thumbnails", but those would be more than just images - maybe they would be a <div> wrapped around an image of the book cover with supporting text. I would use an SQL query to grab whichever eBooks I am offering for free, and then use PHP to loop through that recordset and dynamically build the HTML to display things in a grid gallery, right? And behind each <div> / image would be a hyperlink like www . mysite . com/products/eb5001 and when the user clicks on the hyperlinked <div> they would be taken to that page, at which point my PHP would grab the $_GET variable (e.g. eb5001) and then use that to query MySQL to get all of the related product details (e.g. Book Title, Description, Original Price, Images, etc.), right? And then on that product details page I would have an "Add to Cart" button to allow them to select it. How does that sound?

True, but I guess I have felt more comfortable with $_POST since - as far as I know - it cannot be seen by the user or fiddled with. (Of course I always sanitize incoming requests either way?!) Do you have any thoughts - as a designer or a as an end-user - of what you would expect to see from what I described above? I'm thinking that just having a thumbnail probably isn't very "accessible", so maybe I have to "frame" the thumbnail in a <div> and add some readable text? Also, would it be intuitive enough to an end user with a gallery of thumbnails for them to know that they have to click on the book they want, and then presumably they will dive deeper and get more product details? (I think most e-commerce sites have larger descriptive text when you shop a product catalog, however since I am building this to offer a "FREE eBook" with the purchase of a description, and thus it is a free add-on, I think the experience should be more steamlined, if you follow my thinking?) Anyways, I'm curious to hear what you and others have to say! 🙂

Well, what would you expect as a customer? If I just have a thumbnail which is an image of an eBook, then there wouldn't be any text for search engines to crawl and I suppose it would create accessibility issues if you couldn't see the image, right? For whatever reason, I have never felt comfortable with $_GET requests. Would there be a way to do what I described but submit the request eBook as a $_POST instead? Also, from what I described above, what other design considerations would you make? (Like I said, I have never built an e-commerce site before from scratch, so all of this feels foreign to me!!) Thanks.

Hello. I am rolling my first-ever e-commerce site, and could use some help on designing a product gallery. My site will be selling books and guides, and similar to what you might see on Amazon or Barnes & Noble, I want to create a product gallery which displays all products for a given category. For simplicity, let's say that I am only selling paper books, and that is what I want to display - so for the purposes of this conversation, no need to filter on product type. When a user clicks on the product catalog, I was thinking of simply displaying all products (e.g. eBooks) in gallery containing thumbnails in a grid arrangement. The user would click on the thumbnail - which would be the cover of the book - and then be taken to a product page which would have all of the details, including: a larger thumbnail of the book, book title, description, price, author, etc. I suppose I could have a test title and description below each thumbnail? Anyways, I am a little uncertain of how all of this would work from a technical standpoint?! I guess I was thinking that each thumbnail would have a link behind it, which would then load my "product_details.php" page AND pass along something like a "ProductID" in the URL, so that my product_details.php" script could query my database and pull up the book's details. How does that sound? I look forward to hearing what you PHP gurus have to say!! 🙂

Hashes are commonly used during account registration when you want to verify someone's email. You create a hash, store it in the database, sne dthe new user a link using that hash, and if they arrive at the email confirmation script with that hash, you activate their account. In that case, it is treated as a long random set of digits sort of like a password that a stranger could not mathematically guess.

A-ha I always scrub user data before using it, so that isn't an issue. I just had a fear that the hidden values could be easily altered by a hacker. That's a wrong assertion. I bet that HTML6 and CSS4 will have some improvements over what is currently available. Should I wait until they come out? Using older version of code doesn't necessarily make it "wrong" or "insecure", and "in the real" world, you can't keep perfecting things before you ship them otherwise you never ship anything!

Sounds like < button > is HTML5? I'm behind the times and just trying to get my website done... If using hidden values does NOT pose any security risks, then I think I'd prefer to use that approach since it is more familiar to me. May seem funny, but I don't want to start changing my approach when I am 90% done. I can upgrade my approaches when I start on v2.0 next year.

You missed what I am doing and the question... I have a page with 3 boxes side by side like this... So each plan would be its own form, but I need a way to send in my $_POST some variable/value so my script knows which plan was chosen and then write that in the shopping cart table. That is the design I want - nothing else. So back to my OP... Is there any problem using hidden form values to pay a product_code to my script?

Many many years of experience... 😉

Did you try @Barand's approach? How did it work out?

I wasn't trying to sound sarcastic, but I still don't follow what you are trying to accomplish in real life. Why do you want a product name, color and every SKU associated with it on one row? What happens if you have 25 SKUs of Blue Pliers? If this is a report, I think there is a better way to communicate things. Follow me?

Is there anything wrong (or insecure) with using hidden form fields? I am working on a page where the user can choose one of 4 different subscription options. The approach I was going to use is to have a separate form for each plan, and when the user chooses one, submit a hidden form value so my script knows which subscription plan to grab out of the database. Thoughts?

Why not step back and explain what you want in English... What are you trying to accomplish from a business standpoint? Figure out the real-life problem you want to solve, and then use PHP/mySQL to try and help automate things.

@kicken If that is all I used, then yes. But I believe I mentioned AND'ing with things like cardholder name. Betty Walker in Columbus, OH with Mastercard ending in 9917 would almost always be unique. Of course if I did all of that, then I'd definitely need to be sure the hashing was secure! @Zane, I was thinking that while your idea above might solve my problem, a place where it would ultimately most likely fail is that I bet Authorize.net does not allow merchants to retain transaction data indefinitely. If that was the case - and it seems to me that it is - then I'd need to build my own permanent dataset and find a way to protect it.

Can I remove the .php using a mod_rewrite, or is that more resource intensive? Where would the code you provided above go?

Thanks for the rants and thoughts! 😉 Ironically I got an Auhorze.net account nearly that long ago, and then my business got tabled, and so I just pay $$ each month and don't use it. But *hopefully* before te end of the year I will be online at last and able to collect $$$ ! 😎 I'm trying, but is a journey for sure! Yeah, I have heard that about mail servers. On my VPS I have a mail server - I guess - and I don't get anymore spam than on my personal email accounts. However, it is ultimately managed by my webhost and apparently they do a good job of securing it. Rant away - all very interesting and useful in some way to me! Once my site is up (and making $$), I would like to try and get a penetration testing cert so I will be better able to try and hack my own site and use that knowledge to strengthen it. But right now I am struggling to get my site done, so one thing at a time! Yes, you have a point. Although, the goal is to not remain a "minuscule website" for long! As my business grows, I'm sure I will be more of a target - people hate to see others succeed and love to knock them down. I think they are considered one of the more secure payment processors, but who knows these days?! True. But since I choose to run a business online, I want to do the best job I can to protect things. And I'm sure it can be done, the challenge is just figuring out where the priorities are at and then getting good advice to firm things up.

Does showing .php on the end of web pages pose any security risk? My websites uses mod_rewrites pretty extensively, e.g. www.mysite.com/profiles/saranaclake www.mysite.com/subscribe/view-offers However I still have a lot of web pages which are static pages that end with .php and I'm wondering if I should clean that up both for aesthetic reasons and for security...

@Zane, Sounds like you have hands-on experience using Authorize.net, huh? How do you think they compare to other payment processors as far as programming APIs? And how secure do you think they are in this day and age of perpetual data breaches?

@Zane, Thank you for the information!! 👍 Over the next couple of weeks, I hope to get my checkout process coded. As I get closer to the part where I submit the payment to Authorize.net, then I will have to actually learn what all Authorize.net offers to me as a merchant, including what you are talking about. So if I implemented what you described, would that basically remove most risk that I would have with needing to know who my customers are but not wanting to store their credit card details? And how hard do you think it would be to code in PHP what I described? I have never worked with an API - is it as simple as just passing data back and forth to Authorize.net?

Sure. First off, I am always open to suggestions on improving business processes and customer experience! I have build a website that offers free content to all, and who those with a paid account, they get access to premium content and lots of other features like the ability to post comments, create profiles, pm each other, etc. A customer gets access to these "premium" features through purchasing a paid subscription quite similar to an online news paper like the NY Times or LA Times. The user would click on a "Subscribe" button, be shown a couple of different subscription plans, make a choice and check out. During checkout, the user both creates and account on the spot and pays with a credit card for whatever subscription they choose (e.g. Platinum Plan for $50/year). After doing some field research, people have told me that I should probably allow at least a couple of people to use the same credit card. For example, maybe a mom buys a subscription, loves my site, and as a gift buys her daughter away in college a subscription too. I am okay with maybe 2 accounts linked to one credit card (e.g. husband and wife, mother and daughter, etc.), however, I do NOT want to allow an unlimited number of accounts to a credit card. Why? Because I am attempting to use the credit card to link an online account on my website to a *real* person in real life. If I let Mrs. Jones buy accounts for her husband and ten kids, then is user#7@mail.com started causing issues on my site, i wouldn't know if it was the cardholder or her husand or one of her 10 kids. I could limit things to one account ("supermom@gmail.com") per cardholder name ("Mary Thompson") and credit card # ("4570 1111 2222 3333") but I'm thinking that might be a bit too draconian. But as mentioned above, I also don't want an unlimited amount, because your credit card to me is as much about *trying* to establish ho you are in real life as it is to take your money!! Make sense? So ultimately I need a way to know that user#1 is linked to credit card #1 so if that customer comes back and tries to open 10 more accounts, then I can stop them. Furthermore, if user#1 get kicked off of my site, and comes back and comes back later on and tries to register user#999 using the same credit card (and thus cardholder name) then I want to know that and STOP them from registering again. Also make sense? Of course I don't want to retain cardholder names and credit card #s, but if hashing is as hard to crack as a lot of people say, then i was wondering if storing a hash of the card type and last-4 (and possibly the cardholder name also) would be a way to accomplish what I need above, but also minimize my risk if there was an attack or data breach on my website. Hopefully that give you a better picture of functionality that I'd really like to implement to help *me* control who is on my site!

@Zane, I was afraid you might say what you just did... 😞 For the record, no, I am not storing anyone's credit card details. I am storing username, email address and hashed password at this point. I actually do use Authorize.net although I haven't learned how to hook it up to my website - that is what i am working on now, building the ecommrce portion. To my larger question... I have a business rule that says, "There can be no more than two paid accounts associated with any given credit card.". I *think*, but don't recall since I am learning about my payment gateway, that Authorize.net retains the payment details so I could do the above manually, but that wouldn't be practical, because I am trying to prevent one credit card holder from creating dozens of paid accounts. I was thinking of taking the card type and last-4 and hashing them and then storing them in my database. Then each time a person tries to purchase a new account, I would take the card type and last-4, hash it, and then compare that value to what is in my database. if they match, then I would display an error message, "Only two accounts per cardholder". If the hashes do NOT match, then I would allow the transaction to go through. Hopefully that makes sense. How dangerous and how much of a liability would it be to do that?

I am familiar with what PCI compliance is - can't say I know what it says in 2019. And since PCI is a "policy" document that does NOT - at least when I studied it years ago - dictate "implementation", I figured it safer to ask coding experts about how to securely store things like passwords and maybe more. So back to my earlier question... 1.) Is I use PHP's password_hash() is that suffciently secure that if my website ever got hacked, that I would have time to notify users to reset their passwords and basically everyone would be safe? 1b.) OR, is password_hash() and bycrypt NOT secure enough to offer that level of protection? 2.) If the answer to 1b.) is "Not secure enough to offer that level of protection", then what is? 3.) Is there any practical way to store something like the last-4 of a credit card in a hash and have it NOT be hackable except maybe by some nation-state? Or put more simply, how do companies store things like customer names and billing details so they can manage customers and provide further services, AND how do companies retain full credit card details for things like recurring billing? Yes, these may be steep "asks", but hey, i want to learn how larger companies do this, because it is important to growing a business. (And there must be a secure way to do such things online, because lots of companies already do!) Again, just trying to expand my knowledge... 🙂

At no point did I say that I intended on rewriting password_hash(0 or bcrypt?! I'm just asking questions like "Is there something more secure?" and "Do I need to do anything else to make it secure" and so on.

Your logic is way off today. No, I have NOT critiqued anything regarding how PHP hashes data. I DID say that I would like to better understand how things work and what options are out there so I can make more informed decisions. To say, "Just use password_hash, and don't try to learn anything about it" is a great formula for getting into a security issue down the road. I no longer work on my own car, but I pretty much understand how everything in it works. And so when I make choices on maintaining or repairing my car, I can make wiser decisions.