Web Design Forum: Connetu_C - Viewing Profile - Web Design Forum

I don't think so. Isn't the reason for images not showing usually to avoid the old "embed and hit" routine - when an e-mail loads it requests the image from the target server and hence they know you've opened the e-mail? By encoding a key (or even the full e-mail address) in the image URL, it used to be used by spammers and bulk mailers to verify that addresses were real and worth sending more of their junk to.

I think you can usually avoid this by embedding the images inside the e-mail (as multipart MIME). But then you can get some very large e-mails which will increase your bandwidth, their download time, and may bounce at certain mail servers.

Jay Gilford, on 09 May 2011 - 10:22 AM, said:

Yes, you can use the X-Sendfile method to do that, with PHP first handling the authentication etc. Obviously if the PHP bit isn't doing something critical or amazing, then it's slowing the process down though; useful, but definitely not a replacement for the Web server serving static resources directly.

web-itec, on 07 May 2011 - 06:03 PM, said:

The short answer to this is "no". Stand back for a minute and think about how you are going to do this: you will probably want to use an <img src="..." /> tag in your HTML. The src attribute has to be a URL of a publicly accessible resource - i.e. it is impossible to give the user access to the image without it having a URL it can be found at!

You're basically wanting a resource which needs to be accessible, not to be accessible... errr... see the problem?

Perhaps you should look at authentication/authorisation - so that the image always exists at the URL, but access is denied if the user is not logged in?

Jay Gilford said:

Placing outside the Web root will ensure the image is never available via your Web server - you would never be able to access it through a URL without using a controller script to fetch the file from disk and present it at another URL (this is highly inefficient, as the file has to be read from disk into RAM, using CPU, and then out to network - Web servers tend to serve static content using sendfile or similar to copy directly from disk to network without all the intermediate processing).

Possible solution: If you don't want to use authorisation, then off the top of my head one solution is to use a PHP controller which is used to fetch the images from disk. Each time you need an image, ask the controller to generate a one-time secret key which maps to an image on disk. Then use the secret key as the argument to your controller in the img src URL generated into the HTML page. The controller will return the image on the first request for the key, then destroy the key-image mapping. So if it were called for a second time, the key would not be found and it would return a 404. BUT this is useless in practise to protect an image from theft as anyone can still download to their hard drive if they know their way around browsers, caches and various simple HTTP tools.

Not sure what exactly you're trying to achieve, but the general rule is that if you give any access for something to somebody, then they can always steal it by one means or another! The only way to have complete security is to prevent anyone ever looking at something - which usually defeats the entire point!

For low volumes, it'll be easiest if you use a third party payment provider like PayPal, MoneyBookers etc.

If you go down the road of doing this more in-house (lower cost per transaction), there are still a number of solutions. At a minimum you will need a Merchant Account with a UK provider (this is not the same as a commercial/business bank account) - this is the most difficult part as you may be declined due to risk. After you have a Merchant Account (or before setting it up), talk to several merchant payment service providers. These providers will collect the details on your behalf, via the merchant account, the latter who will (after a few days) then deposit the funds in your UK bank account.

Solutions with a payment service provider range from them hosting everything (much like PayPal, but depending on transaction volume with lower fees), to you hosting only an SSL payment page, to you hosting everything and only passing them API calls with transaction details.

Be aware that as you take more responsibility on yourself, you will need to become more stringent with PCI compliance - the industry standard for ensuring security of card acceptance. If you are doing any of the payment processing/hosting yourself, at a minimum you would need to complete a self-assessment questionnaire and pay for quarterly network scans.

In most cases it is simplest to either use a complete outsourced solution like PayPal, or to use a merchant provider's fully hosted solution, unless you require additional functionality not provided by either of those approaches.

pbb76, on 09 April 2011 - 10:49 PM, said:

I'll assume you either have login credentials to the server and/or the ability to create Web-facing dynamic content (e.g. PHP or ASP scripts), otherwise this is never going to happen. So...

If you only want to list the files and not retrieve them, and your remote server is Linux based, you can use a remote SSH command execution - e.g. using the PHP SSH2 extension. You can execute "ls <path>" for example to get a list of filenames (only) in the <path> directory. Other variations including file sizes, owners, permissions etc. are all available with various ls options.

Alternatively, if the remote server is a web server, why not expose on that a directory listing which you can retrieve via HTTP -- e.g. using PHP cURL. Process the returned HTTP content and send that to your users.