UPCOMING: Link/Form Encryption, Price Spoofing

brettbrett FoxyCart Team
in Bugs & Feature Requests edited February 2010
Hi all.
While the Link/Form Encryption request has received a lot of votes, it's generally been kind of a sleeper request in that not many people were very vocal about it. This makes sense, since the people doing high enough volume for it to be a problem typically implemented another solution such as verifying via the XML datafeed.

Recently, however, people have been asking a bit more frequently. We've had a solution mapped out for a long time (2.5 years is when we wrote out the initial plan), and we've implemented it for inclusion in a future release (probably our next).

To that end, we'd like to share the documentation for this solution prior to its release to get some feedback.

http://wiki.foxycart.com/docs:cart:validation

A few things to note:
- Nobody else we've ever seen or heard about has done anything close to the "form" method we've built. Yes, it seems like overkill and is potentially confusing, but before you knock it please try to think of how to take a form with 10 select boxes, each with 5 values, and validate that using another method. We _THINK_ it's the best solution at this point, balancing ease of implementation with the myriad possibilities, it's possible we've missed something.

That said, if you read it thinking, "Wow, I think it could be way simpler," please let us know where you had that thought, and how you think it _should_ be implemented. Again, it's possible we've missed something, but there really is a reason for it being implemented the way it is, and we'd like to address those types of thoughts in the documentation just so everybody understands the rationale as they're processing the docs in the firs tplace.

- HMAC is a very established standard, but it isn't available in PHP4 by default. You'd need PECL or something. Since PHP4 is not really the default version on 99% of the hosting plans out there, we don't feel like this is an issue. Other languages like Python, Ruby, and .NET all have readily available implementations. We chose SHA-256 over other hashing algorithms because we figured that if you have access to HMAC you likely have access to SHA-256, and we might as well go with it to make things that much more secure (even though SHA-1 would be fine for basically all intents and purposes). More on HMAC over straight hashing. Interesting stuff worth understanding.

- We've tried to make the documentation both complete and approachable (if long). We really want this to be easily understandable and accessible to even the "average" web designer with no real programming experience. Please let us know where you get stuck or if something's confusing.

So that said, please read it over and share your thoughts. We're here to serve our users, and we believe that this solution will be a very Good Thing, but we always want as much dialog as possible. Thanks!
Comments
  • oskayoskay Member
    edited February 2010
    Interesting to see this one move to the front of the line.
    This method prevents spoofing attempts by requiring all links and form values to be “signed” using your “secret”.
    Unless I missed it, you didn't say how that would be required. I presume you would add a checkbox in the store settings (or maybe "advanced") to require encryption on all links. If it's not required for the full store, spoofing is still possible.
    if you read it thinking, "Wow, I think it could be way simpler," please let us know where you had that thought
    I'll bite. I thought this would be way simpler. :)

    Why so many separate encryption operations? Why such long URLs? So far as I can tell, nobody else does it that way.
    Is there really a good strong argument against creating a encrypted version or signature for the full product link or form? I understand that there's some subtlety to the hashing/HMAC, and so on, but we're not protecting a secret (except for the signature private key). The cart contents are *not* a secret, so at least some of the standard analysis does not apply.

    Possibly useful idea: if a complex form were encrypted, --with all of its options listed, including possible OPEN/wildcard options-- then that full encrypted form could be fed to foxycart, along with the clear text version that specified only the *selected* options. Foxycart checks to make sure that the selected ones are "legal" by the defined options on the form.

    Possibly wacky idea for higher security without (many) more bits: Use a rolling key. One-time keys are requested in real time from a foxycart server, using the API key, tagged by the session ID.

    Important observation: This looks *hard as hell* to implement in comparison to regular foxycart "HTML" code, or especially in comparison to encrypted Paypal buttons.
    You should seriously consider adding an automatic encrypted form generator on the Admin panel. A user copy-pastes their link or form (or full static HTML document containing foxycart links and or forms) in the box, and it spits out a signed version for them to paste back in their HTML page. It doesn't need to handle scripts or unusual cases, but it would be very straightforward for you to make this process genuinely easy for 90% of your users that are doing static code in HTML pages.
    Also: I suggest that you should create a PHP example function that wraps the *entire* form, not once per option. The function can step through the tags and figure out which of the inputs need to be signed. This will leave the forms *much* easier to read, and will make all of your existing documentation much more applicable.
    <?php fc_hmac(<form action="http://yourdomain.foxycart.tld/cart"; method="post" accept-charset="utf-8" class="foxycart">
    	<input type="hidden" name="name" value="Example T-Shirt" />
    	<input type="hidden" name="code" value="abc123" />
    	<input type="hidden" name="price" value="25" />
    	<select name="size">
    		<option value="small{p-2}">Small</option>
    		<option value="medium">Medium</option>
    		<option value="large{p+3}">Large</option>
    	</select>
    	<label>Qty: <input type="text" name="quantity" value="" /></label>
    	<p><input type="submit" value="Buy It! &rarr;"></p>
    </form>) ?>
    
    
    
  • brettbrett FoxyCart Team
    edited February 2010
    Unless I missed it, you didn't say how that would be required. I presume you would add a checkbox in the store settings (or maybe "advanced") to require encryption on all links. If it's not required for the full store, spoofing is still possible.
    Good question. The store settings will be all or none.
    Why so many separate encryption operations? Why such long URLs? So far as I can tell, nobody else does it that way.
    Very few people do anything like this in the first place, but Mals E does a (MD5, not HMAC) hash of secret.name.price.quantity. PayPal encrypts entire strings and values using public/private key encryption, which is not only kind of beastly for the average user to set up, but generates even longer strings. That method also doesn't really have much flexibility, as you can't have form values modify other values as far as I know (though I could be wrong; it is beastly and I'm only seen their docs a few times and never implemented that approach myself).

    As far as "separate encryption options": There are just 2 different methods, and which is used is determined automatically based on the input submitted. One where the entire query string is hashed. The other where each individual value is hashed.
    Is there really a good strong argument against creating a encrypted version or signature for the full product link or form?
    The "link" method is just that. You sign the entire query string.

    Also worth noting is that encryption isn't as good as hashing for what we're doing (in our opinion) because:
    - Hashing is much, much faster.
    - Like you said, the only secret is the key itself. No need to encrypt everything.
    I understand that there's some subtlety to the hashing/HMAC, and so on, but we're not protecting a secret (except for the signature private key). The cart contents are *not* a secret, so at least some of the standard analysis does not apply.
    I'm not sure I follow here. There are really only two options: Encryption and hashing. In order for either to be effective, a secret is required. ... The only way to effectively "sign" (ie. verify) any data you (as a secret-holder) send to FoxyCart is to hash it. There's no other option, as far as I can think it through. No?
    Possibly useful idea: if a complex form were encrypted, --with all of its options listed, including possible OPEN/wildcard options-- then that full encrypted form could be fed to foxycart, along with the clear text version that specified only the *selected* options. Foxycart checks to make sure that the selected ones are "legal" by the defined options on the form.
    A few things:
    How would you see the encrypted form being sent? A big chunk of HTML could easily be over the 2083 character GET limit that IE has if encrypted. And the HTML itself isn't the secret, so why bother encrypting it at all when an HMAC hash will get you the same level of verification when paired with cleartext HTML? Regardless, I don't think that's the issue.

    Even if it weren't encrypted, you'd still have to submit a big ol' chunk of HTML? Or perhaps you could submit _all_ the possible options as a serialized and signed name/value pair string. Then FC could see if the selected options are valid. This approach also would necessitate sending a potentially huge amount of data along with the form submission. Yes, adding hashes to every submitted value in the "form" method adds a lot of weight to the request, but so would a giant string of every possible option in a form. That said, it's an interesting idea. But...

    If that method were taken, you'd then have to enter all your form values in 2 places. While this could conceivably be automated (regex to find all strings inside of value="(match this)", pair them with the associated name="" value that's either inside the same <input /> element or from a parent <select> element. It'd be possible, but most people aren't that great at regex. Is it not easier to just run the names/values through a quick function to sign them individually?
    Possibly wacky idea for higher security without (many) more bits: Use a rolling key. One-time keys are requested in real time from a foxycart server, using the API key, tagged by the session ID.
    Cool idea, but adds more overhead and nothing else (I don't think?). HMAC with a secret has been used for the foundation of internet security and is considered to be very secure. So long as the secret is indeed a secret it really doesn't need to be changed.


    (CONTINUED...)
  • brettbrett FoxyCart Team
    edited February 2010
    Important observation: This looks *hard as hell* to implement in comparison to regular foxycart "HTML" code, or especially in comparison to encrypted Paypal buttons.
    The "link" method really is pretty straightforward, no?
    <a href="<?php fc_hash_querystring('name=Test Product&price=10'); ?>">Buy It Now!</a>
    <a href="<?php fc_hash_querystring('name=Another Test&price=20&color=red'); ?>">Buy It Now!</a>
    
    That's basically exactly the same as a normal link, right? Just wrapped in a function. You don't even need to enter your FC cart domain because that's already set.

    As far as PayPal goes, are you talking about generating a button from their web interface or are you talking about the dynamic version? I'm assuming the former, as the latter definitely isn't easier than this is ;)

    That said, yes, we'll probably build a quick link generator. The form generator, however, is a bit more interesting. Again, it's just a lot of regex, and there are a variety of ways to screw it up. That said, I am kind of in love with regex, so once we finalize the functionality I may try adding a "hash_form" method to the FoxyCart_Helper class on that doc page.

    I'm probably not understanding the "encrypt the form" idea you mentioned above. I could see the "sign the whole serialized array of options and verify against that" approach being really interesting, but I think it'd be significantly more difficult to actually implement automatically, and implementing it manually would be a whole lot of no fun at all.

    Thx as always, @oskay, for the great dialog.
  • oskayoskay Member
    edited February 2010
    I was trying to make a number of independent suggestions, and I'm not sure that I communicated many of them.

    >As far as "separate encryption options": There are just 2 different methods

    This isn't at all what I was asking about. I was asking why there are so many *operations.* I don't see why running twenty separate hash function calls in a single form is necessary. Nor do I see why sending twenty separate signatures for a form is necessary.

    The "link" method really is pretty straightforward, no?
    <a href="<?php fc_hash_querystring('name=Test Product&price=10'); ?>">Buy It Now!</a>
    <a href="<?php fc_hash_querystring('name=Another Test&price=20&color=red'); ?>">Buy It Now!</a>
    

    That's basically exactly the same as a normal link, right? Just wrapped in a function. You don't even need to enter your FC cart domain because that's already set.

    Just no. From a design standpoint, I *really* can't understand how you would say that this is better or simpler than a wrapper that you put around the entire link. From the simple standpoint of backwards compatibility, I'm actually very surprised that you're suggesting it at all.

    Let me rephrase my suggestion, starting with your link and form examples:
    <a href="https://yourdomain.foxycart.com/cart?name=Test&price=10">Buy It Now!</a>
    
    <form action="http://yourdomain.foxycart.tld/cart"; method="post" accept-charset="utf-8" class="foxycart">
    	<input type="hidden" name="name" value="Example T-Shirt" />
    	<input type="hidden" name="code" value="abc123" />
    	<input type="hidden" name="price" value="25" />
    	<select name="size">
    		<option value="small{p-2}">Small</option>
    		<option value="medium">Medium</option>
    		<option value="large{p+3}">Large</option>
    	</select>
    	<label>Qty: <input type="text" name="quantity" value="" /></label>
    	<p><input type="submit" value="Buy It! &rarr;"></p>
    </form>
    

    All of your existing documentation and examples and third-party integrations are designed to build links and forms like these. Now, my suggestion: Create a PHP wrapper function to put around a link or form that you want to (notice that I'm not using the word encrypt) verify:

    <?php fc_hmac(
       <a href="https://yourdomain.foxycart.com/cart?name=Test&price=10">Buy It Now!</a>
    ) ?>
    
    <?php fc_hmac(
        <form action="http://yourdomain.foxycart.tld/cart"; method="post" accept-charset="utf-8" class="foxycart">
    	<input type="hidden" name="name" value="Example T-Shirt" />
    	<input type="hidden" name="code" value="abc123" />
    	<input type="hidden" name="price" value="25" />
    	<select name="size">
    		<option value="small{p-2}">Small</option>
    		<option value="medium">Medium</option>
    		<option value="large{p+3}">Large</option>
    	</select>
    	<label>Qty: <input type="text" name="quantity" value="" /></label>
    	<p><input type="submit" value="Buy It! &rarr;"></p>
    </form>
    ) ?>
    

    This is a *tiny* change to the web page-- adding a PHP wrapper around the link or form. 100% backwards compatible within the wrapper-- all of your documentation still makes sense.

    This becomes, upon execution of the PHP, the exact same "signed" HTML that you already plan to support:
    <a href="https://yourdomain.foxycart.tld/cart?name=Test Product&price=10&amp;hash=cbadab30b474c66d02d75046670530ce82f1626b36520a4e4b949a5c1fa037df">Buy It Now!</a>
    
    <form action="http://yourdomain.foxycart.tld/cart"; method="post" accept-charset="utf-8" class="foxycart">
    	<input type="hidden" name="name" value="Example T-Shirt||f8d3b7b993380dee31ee467984397ed8dc5feec3eb464bc55264cbe33fd691ac" />
    	<input type="hidden" name="code||8211b9acfbe1ae395dc32bf5ccfa20ab50382d48a65fa3586803288aacbe9ca4" value="abc123" />
    	<input type="hidden" name="price||f842ce83aff26e640c1958c3f6f9cba033fbe2a9e53c91b92004d32ee185457c" value="25" />
    	<select name="size">
    		<option value="small{p-2}||14696b9ff099727a798a5b59d71bc1540a5481adfd957ed2252acf8aec83914a">Small</option>
    		<option value="medium||713800d729f987d4609a8b83b60932e64f64690b4c2842b7d6522a62fe514af4">Medium</option>
    		<option value="large{p+3}||c8d37d7c32c3c4fc9fe9703e8cc3456020aa9319dd18816d7f887c6f9c616708">Large</option>
    	</select>
    	<label>Qty: <input type="text" name="quantity||753d51d4675bfb6f0aec5e6fbfd8a2e32cbea620c15a181567b052d350469c50||open" value="" /></label>
    	<p><input type="submit" value="Buy It! &rarr;"></p>
    </form>
    


    Just think about how many support requests you'll save by doing it this way, and I think you might start to see what I'm saying.
  • brettbrett FoxyCart Team
    Sorry if I came off as argumentative or anything. Again, we're sharing this pre-release because we know it's going to be something people care about and have ideas on.
    This isn't at all what I was asking about. I was asking why there are so many *operations.* I don't see why running twenty separate hash function calls in a single form is necessary.
    I think I should clarify what in my mind is the difference between the "FoxyCart" side of things and the "site" side of the fence. I hear you loud and clear on how absolutely insane it _looks_, and how problematic it looks to _implement_, but that's code that lives on the "site" side. It'd ideally be implemented in the CMS and generated fairly transparently to the user.

    Your ideas could definitely be implemented though, and they're good ideas. A little more on that below.
    Nor do I see why sending twenty separate signatures for a form is necessary.
    As in, "I don't see why it's necessary to take this approach," or, "I don't see why it's necessary to run a hashing function in every input's value"?

    If it's the latter, then your suggestion kind of takes care of that need. If it's the former, then the only alternative I see is building a big list of all the possible input names and their possible values, but I don't see an easy way to make that happen manually. That said, the way the functions work, we could add a method like that. I'm just not sure it's better or easier to implement than the other method.

    But the underlying fundamental reason that each and every input needs a signature is because inputs can modify the price, weight, code (and category, soon/eventually). So if you had a size=Small{p-5} input that wasn't signed to belong to a specific code then we haven't addressed the issue of manipulating prices. That's why every form input/value needs to be signed to the specific form. (I know that's not necessarily what you asked about, but in case anybody else is wondering, I feel like it's important to understand that. Otherwise it makes no sense.)

    This is a *tiny* change to the web page-- adding a PHP wrapper around the link or form. 100% backwards compatible within the wrapper-- all of your documentation still makes sense.


    I think that _how_ the links/forms are signed is kind of ancillary to the proposed signing methods though. Whether a function processes an entire form or link versus individual values or query strings is up to the implementation. It obviously makes a big difference for the user, but that wrapping/signing function is something that's basically external from FoxyCart at this point. It's code you run on your server, in your CMS, to get the data ready.

    I like the approach of wrapping the entire form like you've proposed, but it wouldn't be quite that simple or necessarily backwards compatible. From a support standpoint we'd have people getting fatal errors right and left because the entire thing would have to be wrapped in single quotes, and all single quotes inside would have to be escaped. (It could be double quotes, but using single quotes for attribute values isn't nearly as popular, and if it's wrapped in double quotes then you run into problems when you start to use the $, which is pretty standard practice in an add-to-cart form.

    Similarly, wrapping an entire block of HTML when all you want to process is a piece of it isn't something I'd do personally, but I see how it might appeal to some people. Also, that method wouldn't really work if you wanted to generate URLs to be used in javascript or API requests. Making the function more discrete allows for better code reuse, makes it easier to debug, and etc.

    For example, you could quite easily extend the base function that's in the docs to take a larger chunk of input and handle the whole thing.

    To that end though, you might as well create a function to grab the entire page prior to it being sent on request and sign every link and form value automatically. Then you wouldn't have to bother with it at all. And for bonus points you could cache the output so you're not running massive regex replacements on every pageload. But all of that lands squarely on the "site" side of the fence, imo. Would I love to help make that happen? Yes, absolutely. Would it be an official FoxyCart piece of code? Probably not, since supporting it across thousands of site variations, versions, and languages would be really problematic. And we'd probably have the Lasso community sad that we didn't do a Lasso version ;)

    So I guess my questions are:
    1) How do you feel about the underlying functionality that we're talking about?
    2) What system do you use (WP right?), and what'll the best approach be for making this as easy as possible for you and users of your CMS?
  • I'm glad this has jumped up the queue of features that will be added, it will be a nice feature to have to put minds at ease.

    I can see this being just like every other feature you guys have thrown in, in that people have the freedom to develop cool ways to use the encryption to make it easier for other people to pick it up/use it (like oskay's approach above). But there will also be a whole heap of new 'gotchas' for people to trip up on in their implemenations as well. The functionality would want to be really well documented from day dot to try to circumvent this as much as possible. Sure it might mean some extra work for partner developers to earn some cash if FC clients dont quite have the skillset to implement it, but if its frustrating for them then it just gives them a reason to say too hard and move on to another product. Personally (and I know its just the first revision of many) the current documentation would need some more work to make it noob-friendly, but there have been a few comments from different people that they'd love to see more of the docs restructured as well...

    Probably the most 'controversial' aspect of it from my standpoint apart from the 'gotchas' will be the limit to php5, but to be honest if I can move a few clients from php4 to php5 so they can use this, then all the better for everyone really, and more and more cms's are limiting to php5 now too.

    To answer your first question, I think the underlying idea here sounds great, certainly sounds like a decent approach to this.
  • oskayoskay Member
    edited February 2010
    Brett,
    I know how important this is for FoxyCart to get this implemented soon and well, so please don't take my anxiety the wrong way here.

    >but that's code that lives on the "site" side

    That sounds suspiciously like "your end of the boat is sinking." I think that you *should* care about how this looks on the client side.

    Your target audience (thus far) has been web designers, who are indeed a lot that care about elegance. I'm one of your regular users, and you can see from my lack of understanding of PHP above how clueless I'd be about how to implement this in a reasonable fashion.


    >1) How do you feel about the underlying functionality that we're talking about?

    The underlying functionality-- at least the main idea --of creating a verified signature of links and possible form configurations before they are served to the public, is obviously sound.

    I do have significant concerns about the particular implementation. One is from an editing standpoint; the forms are going to be much less readable and harder to create from scratch. It looks pretty contrary to everything else that I've seen from FoxyCart thus far.

    Also, if spaces and periods and other things need to be avoided in inputs, that's worrisome. That's affecting customer-facing cart contents, right? Can one no longer order the shirt printed with "marilyn monroe," it has to be "marilyn_monroe" now? Seems to me that there are some fine pre-processing workarounds that you could help out with that would make this recommendation no longer necessary.

    A bigger concern is that it appears to break at least one current foxycart feature that we really do rely upon: the ability to change or concatenate product codes with options. Many of our products have pop-up menu to select different options, which automatically select or configure different product codes. Our store is also now supporting bundled product discounts, which we implemented by having more than one SKU in the code field, separated by commas-- our XML back end separates the SKUs, looks them up in a MySQL database, and generates formatted and sorted PDF packing slips and invoices for the order.

    (I don't see this part as a necessary part of your implementation. Obviously your scheme requires a unique product ID to tie together which "verified" options go with which product, but I don't see why you would require that ID to be equal to the product_code.)



    >2) What system do you use (WP right?), and what'll the best approach be for making this as easy as possible for you and users of your CMS?

    I represent the HTML users; all of our links and forms were written by hand. Never touched wordpress. (If I was using WP, I'd be now wondering how to install the extension that would let you execute PHP from within content panes.)

    One more suggestion: Allow "verified" links and forms even before the option is set to require them in the Admin panel. That would allow a transition that isn't instantaneous. If we implement this, it will not be overnight.
  • brettbrett FoxyCart Team
    That sounds suspiciously like "your end of the boat is sinking." I think that you *should* care about how this looks on the client side.

    Your target audience (thus far) has been web designers, who are indeed a lot that care about elegance. I'm one of your regular users, and you can see from my lack of understanding of PHP above how clueless I'd be about how to implement this in a reasonable fashion.

    I think the issues here are twofold. First, while the method of getting data to FoxyCart (I believe) is pretty straightforward, it's not really "simple", so I think that's causing some anxiety. Probably the length of the alphanumeric hashes alone is frightful, even though it really is the easiest option for the non-technical user to implement.

    Second, what we've documented so far wasn't really intended to be the end-all solution and guide for non-technical users. The functions provided there are really more for example purposes than anything else. It's clear that we may need to split it up into multiple sections, or possibly just skip the "what/why" and focus on the "how" in a beginner-level tutorial using code we supply.

    Again though, this type of thing is inherently external to FoxyCart, since each system will likely implement its own approach. A lot of users are using EE, MODx, Drupal, and Joomla, not to mention non-PHP CMSs and frameworks like RoR and Django. We'll have to figure out how much will be "official".

    Also, if spaces and periods and other things need to be avoided in inputs, that's worrisome. That's affecting customer-facing cart contents, right? Can one no longer order the shirt printed with "marilyn monroe," it has to be "marilyn_monroe" now? Seems to me that there are some fine pre-processing workarounds that you could help out with that would make this recommendation no longer necessary.
    Nothing is changing in terms of how the cart processes your input. Nothing at all. All this is basically pre-cart-add. You can still use spaces in your URLs if you want. In fact, it'll likely make _more_ sense, since you won't have to worry about URL encoding things in your links (which could be handled automatically by the signing function). Then again, if you're not doing it anyway then you probably don't care, but there are good reasons to URL encode strings when linking.

    For forms, basically nothing changes unless you're using spaces in the input names. If that's the case you can (and will need to) change them to underscores, which display as spaces in the cart anyway.

    A bigger concern is that it appears to break at least one current foxycart feature that we really do rely upon: the ability to change or concatenate product codes with options. Many of our products have pop-up menu to select different options, which automatically select or configure different product codes. Our store is also now supporting bundled product discounts, which we implemented by having more than one SKU in the code field, separated by commas-- our XML back end separates the SKUs, looks them up in a MySQL database, and generates formatted and sorted PDF packing slips and invoices for the order.

    Again, probably really critical to understand is that this doesn't change the ability to concatenate the code. You just need to verify off the single code. It'd be impossible to associate an option with a product if you don't know what product it is, and if there are 3 options that change the code then it'd be impossible to know what to sign against. So, you sign against the one main code, but that code can be modified exactly the same as always (so long as the code-modifying options are signed against the base code).

    It doesn't matter if your code has commas or anything, so long as it's there and that's the same value you're using in the message to sign the allowed options.

    (I don't see this part as a necessary part of your implementation. Obviously your scheme requires a unique product ID to tie together which "verified" options go with which product, but I don't see why you would require that ID to be equal to the product_code.)
    Given the above explanation, this shouldn't be an issue. The code makes the most sense to associate products to, as SKUs are kind of by definition unique.
    I represent the HTML users; all of our links and forms were written by hand. Never touched wordpress. (If I was using WP, I'd be now wondering how to install the extension that would let you execute PHP from within content panes.)
    Just curious: You have a custom implementation with the XML datafeed that's pulling from MySQL, so your tech level is obviously considerably higher than a lot of users who've never touched PHP/XML/MySQL/etc. Even with that, you're extremely turned off by the thought of inserting a function into an href? Just trying to get a feel. Based on all the forum discussions we've had and knowing the awesome-factor of your products you're obviously _very_ smart. I feel like I personally must have catastrophically failed with the documentation and communication of this functionality.

    Regardless, you're hand-coding, and that's wonderful. Question though: Are your pages straight HTML or are you using PHP at all? Includes for header/footer? Includes for nav or columns? If you wanted to modify the entire content section of your site, site-wide (let's say to grab the content prior to being output and verify every link/form in the HTML) is that something that's possible for you in your setup?

    CONTINUED...
  • brettbrett FoxyCart Team
    (Again, I think this kind of illustrates the difficulty we'd have in making a sort of drop-in super-easy-automatic solution, since it's just not something we can possibly know the implementation requirements for.)
    One more suggestion: Allow "verified" links and forms even before the option is set to require them in the Admin panel. That would allow a transition that isn't instantaneous. If we implement this, it will not be overnight.
    How would you like to see that happen? It kind of seems like either you verify them or you don't, though I definitely understand what you're saying. Would you like to see the verification ignored entirely prior to flipping the store to "require verification" mode? Or would you like to see non-verified (not signed at all) cart-adds accepted but mal-verified (incorrectly signed) cart-adds error and properly verified cart-adds accepted? The necessity of a sort of test-mode is clear though, to facilitate the transition.
  • Again though, this type of thing is inherently external to FoxyCart, since each system will likely implement its own approach. A lot of users are using EE, MODx, Drupal, and Joomla, not to mention non-PHP CMSs and frameworks like RoR and Django. We'll have to figure out how much will be "official".

    Yes, that will be an interesting challenge. I presume that *almost* every one of your users will implement this, at least for new stores. Again, I'm very concerned about how much more complex it *looks,* and the degree to which this will affect existing documentation.

    Nothing is changing in terms of how the cart processes your input. Nothing at all. All this is basically pre-cart-add. You can still use spaces in your URLs if you want.

    I'm not sure how to reconcile that with "If you need to use spaces, periods, or other special characters in the name of an input you may experience difficulties. [...] We recommend avoiding spaces and periods in the names of your inputs,"

    Again, probably really critical to understand is that this doesn't change the ability to concatenate the code. You just need to verify off the single code.

    Great-- but it still breaks the ability to select different SKU items from a pop-up menu, and various equivalent integrations. Right now, we have a pop-up menu to select between two objects with different product codes, where *no* product code is set except in the option. I assert that this is a valid construction, as of 060.

    So... Wouldn't a separate "form_code" make more sense, where that form_code is *usually* equal to the product code? After all, the necessity of having a fixed code there is a side-effect of needing to sign individual options as part of that form, rather than necessary from a product label standpoint. Since that that product_code is a variable that has really available for customer use "however you’d like," I suspect that you shouldn't be repurposing it like this.

    You have a custom implementation [...] Even with that, you're extremely turned off by the thought of inserting a function into an href?

    Especially with that. I have a vested interest in your success now, so that I don't have to write another implementation from scratch. As I said, I'm not exactly a PHP wizard. :P

    Also... while I may write the backend, that doesn't mean that I'm necessarily the person editing the product pages.


    >Question though: Are your pages straight HTML or are you using PHP at all?

    Our site is in Joomla, but everything FoxyCart related is hand-coded as HTML in content panes. One of the reasons that I liked FoxyCart in the first place is that we can do this, without the constraints that e-commerce oriented CMS's place on form and layout. I suspect that a lot of your users have setups like this-- one of the really nice things about FoxyCart (up to this point) has been that it has been straightforward to hand-code product links.

    Or would you like to see non-verified (not signed at all) cart-adds accepted but mal-verified (incorrectly signed) cart-adds error and properly verified cart-adds accepted?

    That would be an excellent implementation-- it would allow you to check links one by one in the transition period.
  • brettbrett FoxyCart Team
    Yes, that will be an interesting challenge. I presume that *almost* every one of your users will implement this, at least for new stores. Again, I'm very concerned about how much more complex it *looks,* and the degree to which this will affect existing documentation.

    I think that'll be the most interesting thing to see. Honestly, for the users that _aren't_ using a solution with it pre-built-in (like Foxee) I don't anticipate too many actually using this functionality, but it probably will depend on the ease of implementation.
    Great-- but it still breaks the ability to select different SKU items from a pop-up menu, and various equivalent integrations. Right now, we have a pop-up menu to select between two objects with different product codes, where *no* product code is set except in the option. I assert that this is a valid construction, as of 060.

    Ah... huh. That's ... hmmm... So you have many options (name, price, color, etc.) that are _identical_ with the only difference being submitted to the cart being the code? I don't doubt that this makes sense for you, but I'm having trouble thinking of a situation where a different code wouldn't also want to modify the name of the product or another option.

    What I'd do in that situation would be to have one single hidden input[name=code] and then have your select box modify the code like {c:MyNewCode}. That'd be fully valid, and doesn't fundamentally alter what you're doing already.
    Our site is in Joomla, but everything FoxyCart related is hand-coded as HTML in content panes.
    What I think might make sense would be a giant PHP function that'd take the entire page contents and do some fun regex on the whole thing, and use the existing PHP Helper functions on the docs already. Then each CMS could optionally plug that into whatever appropriate hooks or PreRender events the CMS has.

    Another very real issue for you may be the limitations with inserting PHP into any content block on the CMS. Most CMSs prevent inserting anything like that, as it can be seriously bad for security. So if you're using Joomla I'm not even sure you _could_ stick a function inline, regardless of whether it's wrapping the entire form or just the values to be hashed. I haven't used Joomla since way back when it was 1.0 and split from Mambo, so I have no idea on the state of affairs there, but you may _have_ to take a different approach if you want this functionality.

    (I do anticipate our wonderful community providing a lot of code on this issue. Probably even more if we provide more building blocks. We're definitely not opposed to that, but it's just an issue of how official we make these sorts of "extra" pieces of code that others use for their own implementations.)

    I think we're making progress on understanding your concerns though, which is good. Thanks, as always.
  • Ah... huh. That's ... hmmm... So you have many options (name, price, color, etc.) that are _identical_ with the only difference being submitted to the cart being the code? I don't doubt that this makes sense for you, but I'm having trouble thinking of a situation where a different code wouldn't also want to modify the name of the product or another option.

    There are other differences as well, but that seems irrelevant. Suppose I have product numbers 901 and 302 that are medium silkscreen shirts, with option of Elvis print and Einstein print. Or maybe an option for how much RAM your tablet computer has: 16, 32, or 64 GB of memory. Different products internally, but it makes sense to list them as options to a user.

    What I'd do in that situation would be to have one single hidden input[name=code] and then have your select box modify the code like {c:MyNewCode}. That'd be fully valid, and doesn't fundamentally alter what you're doing already.

    I see-- you could use a "dummy" code value that labels the form but doesn't actually show up in the product code, because it's replaced by the option. Okay.


    >Another very real issue for you may be the limitations with inserting PHP into any content block

    That, I'm not actually concerned about. A self-hosted CMS can be made to do one's bidding.
  • brettbrett FoxyCart Team
    @oskay and others: I'm building a function (in PHP for now, since that's the most common language for our users) that'll take a big chunk of HTML and automatically sign the whole thing, kind of as an extension of @oskay's idea from earlier. I can do (and love doing) the regex for this (and have it mostly functional already), but what I can't do is build plugins for every CMS out there.

    So, I can do a quick plugin for MODx since I know it. The HCC guys will very likely do one for EE through Foxee. Anybody want to tackle Joomla, Wordpress, Drupal, or any other PHP CMSs/frameworks? Or port it to Python or Ruby?
  • That seems like a pretty brilliant solution. I think the regex plugin will work well for designers too.

    I guess the error if the hash is not correct would be a language option in foxy backend?
  • erikzetterikzett Member
    edited March 2010
    This is great, I am using Wordpress and seems likely I can just add the function to my custom folder and simply wrap it with the form in my templates. Would be willing to test it?
  • FC team: please do keep in mind the folks who do not have the ability to run PHP because we are on hosted solutions like SquareSpace! i know of more than a few SquareSpace sites turned to shops with FoxyCart. personally i'm on tumblr of all the ridiculous things. hopefully there is a way for us to take advantage of this somehow as well.
  • brettbrett FoxyCart Team
    I love tumblr, actually, and have my own personal blog there.

    To your comment though: There's really no way to use what we're describing automatically if you can't run a server side language (PHP, Python, Ruby, .NET, etc), but we do plan on allowing a little form that'll do this for you if you enter the criteria. You'll still have to do it manually (ie. put in the info, submit the form, copy out the result, paste it into Tumblr), but you will be able to use it.

    There just simply isn't any way to accomplish this without a server side language. You could conceivably do it in javascript, but you'd have to expose the secrets, which defeats the purpose.

    We won't forget you though ;)
  • groovy.
  • I like this but it could be easier to impement. Couldn't you just pass the URL to a script and have it send a GET to your server withe the encoded string? It would make things a bit easier.

    Example URL might be:

    <a href="hashscrpt.php?name=testproduct&price=10">

    where hashscript.php hashed the query string and sends a get request to FC server and redirects the user to the payment page.

    Hashscript.php could even be hosted on FCs servers and made unique per each store. This seems to easy for me what am I forgetting?
  • brettbrett FoxyCart Team
    If you did that what's to prevent the user from saying &price=1 and sending it on its merry way to be hashed and sent to FoxyCart? Or am I misunderstanding you?

    To be clear, with this implementation you _could_ do that. I just don't think there'd be any reason to. But I could be missing the point entirely, in which case I'd love some clarification.
  • lancelance Member, Community Support Member
    Any idea when this might become available? I'm very interested in seeing this implemented, as it seems the largest hurdle to convincing our clients to go with FoxyCart. Some of our clients are put off by the idea that an order can go through, only to be flagged as invalid during a check against the XML datafeed. I understand their concern in this regard, so the hashing solution seems much better to me.
  • brettbrett FoxyCart Team
    edited July 2010
    Very soon. We're shooting for the next 2 weeks to have it in a semi-public beta. I'm rewriting plugin to basically allow you to hash an entire webpage (hash _all_ links and forms (for however many products you need)) in one go, so you won't actually need to do anything difficult other than just start the output buffer at your <body>, end it at your </body>, and output the helper function.

    So, no firm date, but very soon. We'll post in the forum when we have it ready to test.

    (Also, that bit of code will be PHP only at this point, but if anybody wants to port it to Ruby, Python, or anything that'd work with .NET let me know. The hard stuff is the regex, which is already done.)
  • lancelance Member, Community Support Member
    edited July 2010
    That's great news, Brett! Thanks so much for an awesome product that keeps getting better.
  • Has any progress been made on this?

    Thanks -- Tony
  • lancelance Member, Community Support Member
    Tony,

    This is available now. Check the docs here:

    http://wiki.foxycart.com/v/0.7.0/advanced/hmac_validation

    Lance
Sign In or Register to comment.