Forum Moderators: open
The details...
The form pages allow various degrees of customization... usually the addition of text and graphics in the body area above and below the form. But, if these pages are used directly, the url and title that would be displayed would be that of the reservations service provider, not of, say, the hospitality domain presenting them.
Commonly, what's been done to provide additional branding and customization of the page title and url is to enclose these form pages in a "dedicated" branded frameset. This works fine (I'm even able to get good rankings using the noframes area for optimization) until the site customer gets to the checkout area.
At checkout, the reservation service provider switches to a secure server, and the checkout page remains in the branded frame. Unfortunately, because of the frame, customers can't see the secure icon, and this is affecting conversions. I've thought long and hard, and over the years have also talked to the various site developers dealing with the various reservations services, but we've never been able to come up with a solution that would work for everyone.
For the secure icon to be seen, the page needs to break frame when it enters the secure area. I haven't been able to figure out how this can be accomplished. I can't think of a way of "signalling" to the frameset that the page has entered a secure area, and we generally only have access to the body section of the framed pages (particularly as the reservation process proceeds).
Some folks have suggested that we put the frameset on our own secure server, but this would prevent spidering of the frameset and many of these pages rank well. It would also slow down the booking process. I'd also think that the security services would bawk at putting a secure icon on a frameset with insecure content, which is what the framed page is before checkout.
I should mention that our images are all in a secure directory provided for us, so there's no problem with displaying those.
Thoughts and suggestions welcome.
Some folks have suggested that we put the frameset on our own secure server
I'm thinking that what's needed is to use a scripted solution that loads a new, branded but secure frameset ONLY when someone goes to make their reservation. How to detect that specific click - one that occurs within the framed document - does seem to be a bit knotty, however. It probably would work most smoothly if the service provider cooperates in some way.
However, I'm still a bit stymied on how the scripting details would work.
It probably would work most smoothly if the service provider cooperates in some way.
One would think that the service providers would want to help solve this, as I'm undoubtedly not the only one who's run into this problem... but I'm also sure they don't want to complicate their setup for other users.
I'm guessing that the providers have discovered by experience that allowing too much access to their form pages creates lots of support problems.
I've never dealt with these providers myself. All of the clients or developers I've broached this to have been very reluctant to open up that kind of dialogue. If I had a simple, uncomplicated solution to present, they might go for it.
Judging by some of the code I've seen in the forms, which is incredibly messy, I'm also guessing that if the solution weren't simple and uncomplicated, the providers wouldn't understand it anyway.
I can't imagine what the scripting details would be, either. I'd be happy simply breaking the frameset when we enter the secure area. I think users are familiar enough with this kind of change that I wouldn't mind losing our branded frameset at this point. We could still put a graphic on the page which would work.
An inelegant solution that we use is to add " target="_blank" to the form field, like this: <form name="form" method=post action="http://yourform" target="_blank"> so that when a visitor hits the "send" button, a new window is spawned showing that the next window is indeed secure.
You can mention on the first page that this is a secure page and put an icon from the ssl certifificate provider on the original page stating it is secure...
This helped our conversion rate
An inelegant solution that we use is to add " target="_blank" to the form field, like this: <form name="form" method=post action="http://yourform" target="_blank"> so that when a visitor hits the "send" button, a new window is spawned showing that the next window is indeed secure.
cat - If we could do this when transitioning the checkout stage, I believe this would load the secure page without a frame. Is that what you're saying? Unfortunately, though, we generally don't have access to the form... just to the body content of the page above and below it.
The reservation engine forms are generally the same system-wide to licensees using them, and the providers can't or won't deal with individual variations. So I think it's got to be a script based solution, but we've certainly got most of our hands tied.
<thinking out loud>Somehow, we need to be able to detect a transition to the secure server and use that to break the frame.</thinking out loud>
window.your-frame-name
I just can't see how you can get around a basic security related block: to avoid XSS (cross-site scripting) attacks all modern browsers are designed to block access of scripts to information from a page on a different site.
encyclo - Thanks. I understand the implications of this.
I'm not a programmer, though, so I'm not picking up on what you mean by this next suggestion at all...
You could try a Javascript solution where you would look for the link within the content with window.your-frame-name.
The coded src link for frame name="bottom" is constant in the frameset. The pages displayed in this frame change during the reservation process, and the one I'd like to detect is the switch to "https." If you're suggesting I look for this change using window.your-frame-name, I don't have a clue where to begin.
Here's a thought, have your customers purchase a secure server for their site. Have all of the reservation pages and others that need to show that they are secure called on the secure server. This will indicate to the visitor that they are in a secure area (because they are).
As long as the ssl certificate is bought for your clients specific domain name, all browsers will recognize these framed pages as secure, when they hit the submit button, they will remain on their ssl pages within the frame and still show that they are secure.
Seems too simple, but I can't see why it would not work.
Seems too simple, but I can't see why it would not work.
Maybe I haven't stated the situation clearly enough. All of the reservation pages are on the providers' servers, on their own various closed systems.
As I understand it from my clients, to get the kind of access to these systems that would allow us to put the material on our own server (both the insecure reservation area and then the secure checkout area) would entail a different level of service that would cost thousands of dollars extra a month (when this level of service is available at all).
I don't know how these systems work enough to understand the complications or why that kind of access would be more expensive, but that's what I've been told by various clients with various kinds of reservation systems, and it does make sense. At the least, there would be extra setup, security considerations, and maintenance required by the system provider.
This is in fact why we've used the branded framesets. If we were able to put these pages on our own server, we wouldn't need the frameset at all. If anyone can advise me otherwise, I'd be happy to listen.
That doesn't cost very much, usually $10 or $15 a month.
Just run the whole thing as https, the frames that is.
That means the frames would run as secure, and the content would run as secure, on the other servers. You'd only be running the frames as secure to create the illusion of security, an illusion that in this case would be non-illusion since the framed content would in fact be running on a secure server.
I think what he was suggesting was that you put your framed pages on a secure server, which will show the secure server icon in the address bar.
I'd commented about that idea in my original post....
Some folks have suggested that we put the frameset on our own secure server, but this would prevent spidering of the frameset and many of these pages rank well. It would also slow down the booking process. I'd also think that the security services would bawk at putting a secure icon on a frameset with insecure content, which is what the framed page is before checkout.
Again, I wonder whether a security service would in fact put a secure icon on a frameset displaying insecure content in its frames. But my main concerns would be loss of rankings and a greatly slowed-down booking process.
In our case duplicating the programming isn't that big a deal, doesn't sound like you have that option though.
To be honest, this is the price small people pay I think for not being willing, or not being able to afford, actually creating an app that they own. So losing a few conversions is just the price they pay for not being able or willing to pay the actual price of making an actual self sufficient website.
Given how much I assume it would cost to actually run the programming, as you noted, several thousand per server or whatever, I'd say this is just an accept what you can't change type situation.
