Forum Replies Created
-
Posts
-
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.
What happens if you save the downloaded files first and then open them? Some applications may not like the fact that downloads are being served up in “chunks.”
So that we are on the same wavelength, are you using the eStore S3 Integration feature?
The plugin directory should have 755 permissions. Each of the *.log files should have 644 or 600 permissions.
You might also try changing WP eStore -> Settings -> Addon Settings -> Download Manager Related Settings -> Download Method to # 3 or 6.
Try this?
http://php.bigresource.com/Track/php-yRLczTlq/
The problem seems to be common, but because it is server configuration related everyone’s solution seems to be different.
No it is not. Take a look at the custom download.php file and compare it to the original one. The custom one is meant to be relocatable to directories outside the normal plugin directory. Its sole purpose is to “find” and then call the original download.php file. When you renamed the original file, it gave up, because it couldn’t find it.
So, when the user invokes the custom download.php file, it first goes looking for the original one and then transfers control to it.
