If our Photoshelter login page has looked like it was on drugs recently, with completely screwed up formatting, there’s a good reason. In technical terms, it’s called a lack of CORS (cross-origin resource sharing, not Coors!). Like many other photographers, we use Photoshelter to provide the “back-end” image engine and e-commerce for our website. In general, it’s worked well for us since 2009. We used “Manual Customization” to integrate Photoshelter with our website, so that when a user logs in to make purchases, those purchases are actually made on Photoshelter’s secure servers over an encrypted “SSL” connection, commonly recognized by the “https://” prefix. It has been transparent to the end user, and it has worked well until recently.
So what’s the problem? As internet security has become an ever-increasing concern, browser developers as well as the internet community at large have recognized the ability of malicious hackers to spoof end users with fraudulent information in order to obtain credit card and other personal information. In response, browser manufacturers have tightened the restrictions on server-to-server communications to prevent “bad” code from getting injected into pages that a user views. Therefore, servers that make secure connections for e-commerce, like Photoshelter, now need to make special connections to other servers (like ours) via a CORS protocol. Unfortunately, Photoshelter’s Manual Customization interface was designed before the era of CORS and it has not been (and will not be) updated.
The result is that when a user goes to the photographer’s website login page, for example, Photoshelter appropriately makes a secure connection to a photo buyer’s computer, and then requests that additional information needed to maintain the “look and feel” of the website be downloaded from the photographer’s website to the login page. Because this request is not made with SSL (using the https:// protocol) and requests data from a different server, the browser sees it as potentially insecure and blocks the download of executable data, including Javascript and CSS needed to make the page render (display) correctly. Interestingly, browsers currently recognize “insecure” but non-executable data like jpg, png, and gif images when they are “mixed in” over a secure connection, but they allow those images to be rendered, even though they could provide misleading information to the end user like “Enter your bank routing number” in an otherwise nondescript text box. Regardless, the end result is that the login page and other secure pages being served by Photoshelter were a jumbled mess!
Photoshelter Support claimed to have no fix to this problem, and Photoshelter has decided not to update the “classic” user-customizable templates on which our site (and others) are built, even though the login and other secure pages were completely unusable. Their approach was to ignore the problem and hope users migrated to their new web design framework called Beam. But many photographers with custom websites, including us, don’t like the look or limitations of the Beam platform. One fix was proposed by David Brabyn (http://digitaltechparis.com/2014/12/fix-broken-photoshelter-login-page-problem-firefox-chrome/), but this only dealt with CSS problems and not Javascript problems. Photoshelter Support mentioned this in an email to me, and noted, “You are correct in that this issue will effect all members who are using manual customization (and on all major browsers), and [we have] not found a workaround. There have been members who have reached out to us regarding this same issue before, but I’m aware of only one who has opted to use David’s workaround with success.”
We have found a work-around that requires taking all of the javascript and CSS files that were linked to on our site by Photoshelter and compressing them using javascript and CSS compressors, then embedding that compressed data into the Public and Customer Page Master Templates that Photoshelter uses for manually customized web sites. By doing so, when Photoshelter is serving secure pages, there are no longer insecure (http://) calls from Photoshelter’s servers to our server for javascript or CSS files – the types of files that were blocked from being downloaded and that made page rendering fail. There is still a “mixed content warning” icon in the address bar for the .jpg, .png, .gif, etc files, but by default the images (and the entire page) are rendered correctly. The total character count for the compressed CSS/JS for our website is a handful of bytes over 30,000 characters, and the limit on the Photoshelter templates is around 60k. If the compressed data (and the rest of the HTML template) were larger than this, we would need to resort to pruning out what was not essential, perhaps as recommended by David Brabyn above for CSS.
The CSS compressor we use is CSSCompressor.com (at highest compression), and for javascript compression we use JSCompress.com. Not all compressors are equivalent, and files that are compressed and embedded should be verified individually.
We will migrate to a new website platform in the near future that does not require Photoshelter’s classic templates, and that will work equally well on mobile devices as well as desktops, but for the moment, we’re back in business, with a usable login to our website e-commerse page and light boxes. If you’ve had the same problem, or were confused by our jumbled login and other secure pages, I hope this helps.
Tags: Business, Photoshelter, Website