Link to home
Start Free TrialLog in
Avatar of Gite
GiteFlag for Canada

asked on

History, frames and https

My site is  built with 2 frames:
frame a: a menu
frame b: pages that change according to selections in the menu or according to actions in frame b.

Up to now, this sequence worked well:
1. Typing domain.com as the adress displays both the menu and the "home" page
2. Clicking on Login in the menu gets the Login page in frame b
3. Entering username and password brings a Search page in frame b, including a button to buy a subscription
4. Clicking on the subscription button gets the fee page in frame b, with a buy button
5. Clicking on the buy button gets the user coordinates page in frame bwith a pay button
6. Clicking on the Pay button gets a confirmation page in frame bwith a Goto to secure payment server button
7. Clicking on the Payment server button gets the payment page (https:...) in frame b with credit card number, ... and a Process button
8. Clicking on the Process button with a wrong expiration date gets the Refusal page in frame b. That page is POSTED by the payment server
9. Clicking on the Back to origin button on the Refusal page gets the Search page in frame b through a history.go(-5) command.

It worked well except for one thing: people didn't see the security lock nor the https address when they got the Payment page. Some customers backed off because they feared the payment site was not secure.

To correct that, the payment page is now displayed full screen, using TARGET="_top" to get it over the 2 frames.

THE PROBLEM: in step 9, clicking on the "Back to origin" button gets the user back to:
-frame a: the menu (OK)
-frame b: the "home page" (WRONG)

If the user uses the browser's "Back" button, the page doesn't change. By selecting the "Payment page" in the history, the user gets it, and fromt there on he can click on the browser's Back button 4 times to get the Search page in frame b.

Why is this and do you know a way to solve it? I have to use something like history.go(-5) because there are many pages from which the user can get into a buying sequence, and I want him to go back to where he was, whatever that may be.
Avatar of ahoffmann
ahoffmann
Flag of Germany image

rule #1: don't use frames if security counts
rule #2: there is currently no browser which indicates undoubtly which part of the screen (frame) is secure (https)
conclusion: get rid of frames (if you care about obvious security)
Avatar of Gite

ASKER

impossible in the short temr to do that.
frmaes are unreliable (if security counts). Dot. Period.
You better gowith your target="_top" solution.
Avatar of mhunts
mhunts

You can make the entire site secure. Then the user would always see the https and the lock.

or you could use a popup.
Avatar of Gite

ASKER

Right, but I try not to, to avoid that cost.
you avoid the costs, but the user should pay and be unsecure? I get the feeling that there is something wrong in your idea...
Please let us know if you're interested in a technical secure sugesstion, or just in something insecure and low costs.
Avatar of Gite

ASKER

The user is SAFE NOW. The paysite is a HTTPS server
The only thing I do not like is that because of frames he does not SEE the lock.
That is why I use TARGET="_top" to go to the paysite. That way, the user can see that lock.
But the history.go(-5) does not work on the "Goback to origin" button, AFTER THE PAYMENT has been accepted.
if I don't see the lock, the site is unsave. Dot.
And even if you see the lock, it could be a spoofed page (using iframes or whatever). So getting rid of frames/iframe is first stelp to make it secure.

> .. is that because of frames  ..
that's what I say: see above

Well, I agree that using frames makes some things simple for the programmer (and unreliablefor the user), but if security counts, you have to do it the safe (hard) way: no frames.
Avatar of Gite

ASKER

I will eventually, but that is impossible in the short term. So I need a solution now.
If this is a temporary solution, then you should consider opening a new window for the secure pages. That way the user will see the lock. Not the best, but a good compromise for a temporary solution.
agree with mhunts' last suggestion
Avatar of Gite

ASKER

When I call the HTTPS pay page with TARGET="_top", the user sees the lock. The problem is that when the paysite gives me the control back(say to my Refusal page), I want to give the user the opportunity to go back to where he was before starting the pay process (5 pages ago).

THat is why I offer him a "Back to origin"  button. THat button has a history.go(-5) command.

That commad did work before well I introduced my "TARGET="_top" to get to the pay page. It does not since.

Why do you think opening a new page instead of using TARGET="_top" will be different?
ASKER CERTIFIED SOLUTION
Avatar of mhunts
mhunts

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Gite

ASKER

Thanks. I'll try it with pleasure.
With the two separate windows, it provides a clearer distinction to the user that when they're in the new window, they're in a secure environment, and when they go back, they're in the non-secure environment.
Avatar of Gite

ASKER

FInally, the new window solution has been successfully implemented. THanks