SaranacLake
-
Posts
648 -
Joined
-
Last visited
Posts posted by SaranacLake
-
-
5 minutes ago, requinix said:
User doesn't care. They don't look at URLs when they're just browsing around, and if they want to share the page they'll either use a share button or copy/paste what's up there. In fact that copying and pasting is a huge reason why ideas like putting session IDs into the URL (PHP's session.use_cookies/use_only_cookies) are strongly discouraged.
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!
5 minutes ago, requinix said:That said, try to keep it simple. example.com/product.php?id=123 (or /products/123) is fine. Attempting to obfuscate it because you're scared, like example.com/product.php?product_id=uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8, is not fine. People don't like things they can't understand: "123" is a number and people are okay with numbers, "B00005N5PF" is some sort of cryptic ID but it's okay too because it's short and easy to understand, but "uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8" is a code and codes are for hackers. CoDeS aRe FoR hAcKeRs
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.
5 minutes ago, requinix said:Probably, yeah.
Lots of stuff on the internet already works like that. People are used to it.
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?
-
5 minutes ago, Barand said:
You would only be sending a product id number, not your bank details.
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! 🙂
-
8 hours ago, requinix said:
Is that what you want to do?
Sounds right.
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.
-
26 minutes ago, requinix said:
No, it's from HTML 4. People just didn't really start learning about it until HTML 5 and the push towards semantic markup and better web design.
A-ha
26 minutes ago, requinix said:Any additional risks. Besides a developer having a faulty assumption of "well it's hidden from the user so they can't do anything to it".
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.
26 minutes ago, requinix said:"I know it's wrong but we'll do it right next time"... yeah, if I had a nickel every time someone said that to me...
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!
-
12 minutes ago, requinix said:
Why? You don't need to do that. Managing one form would be simpler than managing three, right?
<button>s support a name and value, as well as a separate (HTML) caption displayed to the user. Compare that to regular <input type=button>s which support a name and (string) value, however the value is also used as the caption.
Sounds like < button > is HTML5?
I'm behind the times and just trying to get my website done...
12 minutes ago, requinix said:Other than the general design of what you're doing? Not especially.
Hidden inputs are for when you want to include data in the form but the user isn't supposed to interact with it. It is no more or less secure than any other form field. You still have to validate it in your script like you would everything else.
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.
-
1 hour ago, ginerjm said:
When the user selects a plan, do you not save that in his "record" for future reference? Once you do that you can always look it up when he logs in and save it as a session var and not have to 'hide' it on the web page.
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?
-
6 minutes ago, StevenOliver said:
I don't know how you know this stuff....
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?
-
1
-
-
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.
-
29 minutes ago, kicken said:
Your ideas regarding trying to limit accounts based on card numbers (particularly only the last-4) and track individuals by card numbers are fundamentally flawed.
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!
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.
-
3 minutes ago, Zane said:
The extension doesn't even have to be .php either. You could have myfile.notphp instead. It's arbitrary.
All you have to do is edit the webserver configuration.
<FilesMatch ".+\.ph(ar|p|tml)|.+\.notphp$"> SetHandler application/x-httpd-php </FilesMatch>
Obscurity only really draws attention though. I mean, if you're a spy trying to blend in, you're not gonna wear a hat saying "not a spy", hopefully.
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! 😉
22 minutes ago, Zane said:It's been over 10 years since I messed with Authorize.net API. I first used it to allow people to make single secure payments from a web page of mine to a bank account. That's it. Back then, they didn't have all of this fancy new stuff. Therefore, i really don't have any valuable comparisons to give.
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 $$$ ! 😎
22 minutes ago, Zane said:Also, I do not consider myself to be anything close to an expert (or even intermediate) level of creating secure systems.
I'm trying, but is a journey for sure!
22 minutes ago, Zane said:I ran a mail server about 6 years ago and that was a total nightmare. Literally, as soon as the server went live, it was plagued with bots and whatever else that started using my SMTP server as an open relay and my IP became blacklisted pretty quickly for spam. I google ad nauseum for how to secure this and how to secure that and what the best practices were, but I was in way over my head with absolutely no budget for anything to help me out. After 4 years of trying to maintain a mail server that successfully sent and received mail with no issues (though, there were still issues), I finally was able to convince my boss to switch to a Google Business account and let them handle all of that guff.
Mail servers are an absolute nightmare that I wouldn't wish upon my worst enemy. I mean, installing SSL certificates is easier than maintaining a mail server.
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.
22 minutes ago, Zane said:Anyway, this topic has nothing to do with mail servers.
Rant away - all very interesting and useful in some way to me!
22 minutes ago, Zane said:You know, I've never tried to even perform a breach in my life. I've never even tried to breach myself. It's an exhausting realm of web development that I avoid like the plague.
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!
22 minutes ago, Zane said:Really, what is secure? Unless you're a Fortune 1000 company or something, I doubt you're going to have a hoard of people trying to hack your site; don't flatter yourself. I was a web developer and ran probably the least secure site, in my opinion, but the audience for that site was so minuscule compared to that of large corporations. It's about the same concept as viruses. Most people running a *nix system do not really need to worry about viruses because *nix systems do not take up much of the market share for personal computers. However, Windows is always being probed and poked and molested because it has a gigantic user-base.
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.
22 minutes ago, Zane said:In any case, Authorize.net seems to have improved pretty much everything they had when I messed with it over a decade ago. Most, if not everything, of what I utilized is gone or deprecated. I mean, I would trust it.
I think they are considered one of the more secure payment processors, but who knows these days?!
22 minutes ago, Zane said:At the end of the day, though, the most secure you'll ever be able to make your system is if you cut it off from the net. If it's not on the internet, you really have nothing to worry about. If you're not connected to the internet, you're not going to get any viruses anytime soon. I know that's not an answer, but it's a hard truth to accept. Online banking is really awesome in my opinion, but I know that at any particular time, something could go awry and cause my life hell.
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...
-
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?
-
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?
-
2 minutes ago, Zane said:
Could you explain the scenario a bit more?
Only two accounts per cardholder. So, a single user can purchase cards, and these are credit cards? It's not so clear what your idea is. Please elaborate.
Or maybe, it's a user cannot add more than two cards to their account.
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!
-
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?
-
3 minutes ago, requinix said:
Credit card data is a whole 'nother ball of wax. If you're storing it in any form and you don't already know about PCI compliance then stop storing it and learn about that.
If you do the hash right. And since that's a hard target to hit, use password_hash().
Not when you know that the input is 15-16 characters long and consists only of digits.
[edit] And one of those digits is a checksum so the real input is actually 14-15 digits.
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... 🙂
-
7 minutes ago, requinix said:
Kinda, yeah. But changing your oil and cryptography are very different things. Your users are trusting you with sensitive information like their email address and password.
If I needed my car to bring me cross-country and I had to bring my spouse and children with me, I wouldn't change my own oil. It's fine that I know how to do it, and for simple situations I would, but when it matters I set aside my own desires and trust the people who really know what they're doing.
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.
-
7 minutes ago, ginerjm said:
So you are basically saying that the people who HAVE learned stuff and HAVE written the php functions to perform hashing for us users already have NOT done a good enough job for you?
Interesting....
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.
Trying to remember name of old framework
in PHP Coding Help
Posted
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?