Forum Replies Created
-
Posts
-
I am trying to find current information on how to change the color of the eMember login button. All of the information that I am finding is either outdated or incomplete or unclear. Could someone please state succinctly how to currently and best change the color of the login button? THANKS!
Actually, after reviewing everything, I realize now it is perfectly OK to use Amazon S3. However the default “AWS S3 Presigned URL Expiry” should be 30 seconds or even less. And it should be used in conjunction with the “Downloadable” setting for digital content to be delivered via an anonymous encrypted download link. Because the link you deliver to the customer is encrypted and then only when they click that link does eStore generate the S3 specific URL with an expiration time. The download attempt is only initiated with the customer follows the encrypted eStore link and that converts to the S3 timed link. It only takes a matter of seconds to go from the encrypted eStore link to the S3 link and initiate the download. Once the download starts, the link can expire and has no effect on the in transit download. After thirty seconds that link is of no use to anyone and it has no effect on the in progress download. My recommendation is to set that default expiry time to a much lower number. The S3 link should be short lived and the customer should rely on the eStore encrypted link to get to the file.
OK. I am having some difficulty understanding the benefit of using S3. I have gone to the trouble of setting up an S3 account specifically for my website and uploading the file to S3 and linking my S3 account to eStore. Now I have linked the file from S3 to the product and generated a encrypted link from the Admin Functions. The generated link works fine. But you are just passing off the download to S3. I now have a long link to the file on S3 that is completely clear. I can copy and past that link to another browser on my PC and download the file over and over directly from S3. Anyone can redistribute this link as long as it remains active. I don’t understand how this is a good or secure distribution method.
It looks like I might be able to implement mod_xsendfile. Would this resolve the issue and allow me to have a hidden download URL?
Or should I just invest the time in implementing Amazon S3 instead?
I am currently using WebHostPro (webhost.pro) and their Advanced VPS plan.
I am currently investigating using Amazon S3. But I don’t quite understand how that would avoid the VPS bottleneck, if that is the issue.
My hosting company said it was set to 512MB and that they rarely change it for anyone. But they agreed to change mine to 1024MB. It didn’t fix the problem. I am also forced to wonder about the wisdom in this download method because if my site is currently low use and it doesn’t work when I am the only person attempting to download a file. I can only imagine multiple people trying to download different files at the same time would be impossible.
Yes, I understand what you are saying. That is unfortunate that the implementation with CCBill is less than ideal. I may need to just work with CCBill’s email notifications for transactions because the webhooks don’t appear to want to function properly and I don’t think I want to spend too much more time trying to troubleshoot the issue.
Your answer is clear, but why CCBill’s webhooks use of the plugin is different is not clear. Why do the other payment gateways have specific URL’s that call the plugin code directly? They don’t talk to a generic port on the root of the website. But you are saying CCBill is going to send me critical data just off a port on the root of my website?
Let’s just be clear, is there a unique URL for CCBill to use for webhooks with the plugin? Because right now, based on the information I have, it is just the generic site URL and this seems wrong. Could someone just answer this question which I have asked multiple times?
Good advice. I just realized that I thought the Approval URL and the Approval Post URL where the same thing. Now I realize that the Approval Post URL requires the specific URL for collecting the necessary data from CCBill. That appears to have resolved this data posting problem. Although the data collection page was created, it hadn’t been populated in the URL on the settings page. So, that was another place I was missing something.
However, returning to the original webhooks issue, as I said at the beginning these are subscriptions for my membership site. CCBill is biling them for recurring memberships. So, I still need to get the data from CCBill to WP eStore when their membership has renewed after 30, 60 or 90 days.
As I said earlier, the CCBill setup instructions did not have a specific webhooks URL. It merely says:
Click Webhooks and set the Webhook URL to the site where you are using the payment gateway bundle addon. Click All so CCBILL sends notification for all the events.
And it shows a generic site URL. So, I have put in my generic site URL. However, in the plugin settings there are very specific webhook URL’s for other payment processors. This seems suspect to me, like I am missing needed information for the CCBill webhooks.
Unfortunately, it appears as though I need a CCBill specific webhook URL that is defined nowhere. It is not in the CCBill configuration documentation and it is not listed in the settings for the plugin. Oddly, other gateway webhook URL’s are listed in the settings but none is listed for CCBill. Could someone please illuminate the darkness for me?
