Forum Replies Created
-
Posts
-
1. Is the seller’s (you) PayPal email address properly configured in eStore?
2 Is the Use Sandbox Mode checkbox unchecked?
Yes. That is correct, you do not have to set permissions. The expiring URL takes care of everything.
Personally, I feel that S3 is the more cost effective option. You gain an unprecedented level of reliability and speed, for a fraction of the cost and aggravation that you’d have to pay for a VPS and all the support costs. The only time I can see S3 not being cost effective, is when you start getting into massive sales levels and downloads.
When eStore does the download processing (no as3tp) it acts as a middleman between the actual file location and the browser. As such, the process was always dependent upon the lack of any resource restrictions on the part of the hosting provider. The as3tp solution does not suffer from this problem. There are simply too many things a provider can do that can mess up the download process. The as3tp process counts on the fact that Amazon is using their own network for their own business (selling books/music) and that they would not allow anything to screwup the download experience for their own customers.
You should be able to use the existing CNAME in the product URL as as3tp://CNAME/folder/object
The 0k file problem was related to eStore handling the downloads. the as3tp is a “hint” to eStore to process using S3. You should be able to use the existing CNAME as part of an as3tp URI as long as it resolves to the correct form, that uses the bucket name as part of the host path… bucket.s3.amazonaws.com/folder/object and not the form that uses the bucket name as part of the directory path… s3.amazonaws.com/bucket/folder/object
There are two expiration periods at work; the expiry of the encrypted eStore URL and the expiry of the pre signed URL. The expiry of the encrypted URL is 24 hours. It can be used multiple times during that expiry period unless you have set the (default 5) number of times it can be used. Each time the encrypted URL is used, a pre signed URL request is generated. Each pre signed URL can also be used multiple times, within the (default 300 second) expiry period.
Correct, once eStore generates the pre signed URL request and transfers control to Amazon, you are no longer constrained by any hosting provider limitations. if you can find a way to break S3 with your downloads, I’m sure Amazon would love to hear from you
Don’t panic about seeing the bucket name in Firefox.
What is happening is that eStore is converting the encrypted URL into a pre signed URL request. The browser is then redirected to the S3 bucket. Because control is passed from eStore to S3, you are free of all the previous problems that occasionally have been plauging eStore users. The request is only valid for less than 5 minutes. If you tried to bookmark the resulting URL, it won’t work after 300 seconds (from the time it is created). You could adjust this time to a lessor value, but only if you are sure that your server’s clock is in sync with the one at Amazon.
As long as the object is (default setting) not marked public in S3 console, you are fine.
Are you trying to “blacklist” certain email addresses from using the squeeze page form? That’s a rather futile exercise, but something could be coded… if there is interest, a “hook” to an external filtering function could be added to the squeeze page form, to validate the information.
As for PayPal is concerned, money is money. If someone successfully completes a PayPal transaction, you really shouldn’t deny them the download, based on their email address.
It would, ***** BUT *****
1. eStore is still acting as the middleman between the buyer and Amazon.
2. Downloads are at the mercy of your hosting provider’s server restrictions.
3. Your S3 file is still “public” to anyone who knows the bucket/folder name.
By using the native S3 integration feature of eStore 4.8.x or higher…
1. The eStore encrypted link is converted into an expiring Amazon S3 URL request.
2. Control is transferred to the S3 server containing your bucket.
3. Download speeds are not limited by the capacity of your server.
4. No more download failures due to hosting provider server issues!
I’m not an eMember or NextGen expert (I do eStore), but I’m not sure about the confidentiality of eMember ID numbers. Could a paparazzi or other nosy person peruse the database by submitting random or sequential ID numbers in the URL?
Can you use a ROT13 or BASE64 encode of the user name and use that as the database index?
One possible scenario is to issue (eMember) login credentials to each customer, and then have them go to a page that only they can access. On this page, have “buy/download now” buttons for products that only pertain to them. You could also have links on that page directing them to a public “accessory” page that sells frames, etc.
In a second scenario, store each customers portrait preview as a product. Then, manually generate and email download links to each electronic preview package. If the customer decides to buy, they can go to a public page and order their print packages. You’d then collect the customer’s name, ID or other code, to determine who gets what.
The major difference between these scenarios is the first scenario requires a new page to be created for each client. Not good if the hired help is not WordPress literate. The second scenario does not require as much computer literacy for the hired help.
