chrometweaks.org

Tell me the iPage web host for the beginners?

Click Here To View All Answers...


Quick question: Tell me the iPage web host for the beginners? Hoping for any answer. Another question on my mind: I'm in the process of setting up my store and have read a lot here about the challenges of operating on a shared server / shared ssl environment as it relates to session id with people ending up with other customers contents in their carts and other security issues..

Is anybody here successfully operating a store in a shared server / shared ssl environment? How did you overcome or avoid those kinds of problems?.

Here's what I've gleaned so far from searching the forum:.

Store sessions in mysql..

Set session directory to something local to your iPage site just in case..

General consensus is to not force cookie use due to shared ssl problems..

Prevent spider sessions TRUE and update your spiders.txt.

Don't check IP address because aol users can't browse your store then..

Recreate sessions TRUE may help in some cases.

I'm curious about how turning on use cache might affect session problems..

Any other comments? How are you keeping your store from having session problems on a shared server / shared ssl envirnoment?..

Comments (18)

I'm stumped. I'm not so sure what is the right answer. I'll do some research and get back to you if I discover an useful answer. You should email the people at iPage as they probably could answer your iPage question..

Comment #1

Wlpywd - thanks for your reply. Glad to hear somebody has had success with this situation...

Comment #2

1. store sessions in mysql. = Yes.

2. set session directory to something local to your iPage site just in case. = Don't need one, if storing in MySQL.

3. general consensus is to not force cookie use due to shared ssl problems = Force Cookie Use only works when the iPage domain and the ssl cert match up..

4. prevent spider sessions TRUE and update your spiders.txt = Yes.

5. don't check IP address because aol users can't browse your store then = Yes.

6. recreate sessions TRUE may help in some cases = Yes.

7. I'm curious about how turning on use cache might affect session problems = Shouldn't have session probs if using mysql to store them..

Vger..

Comment #3

Vger - Thanks for replying. I've seen your comments on many threads in related issues. I'm curious if you have any opinion as to the potential danger of having the session id exposed in the beginning of a browsing session. It seems that for the first link or two from the front of the store, the session is still stored in the url, but thereafter it disappears. Is that normal? That seems to be the way it is working for my store..

I'm worried about problems resulting from someone clicking on a new item on the front page, then posting the resulting link to the item in a forum somewhere complete with the sid. Many of my customers are going to be coming from a devoted fan base and I can easily imagine such a situation happening..

Is there anything that can be done to prevent that initial exposure of the session id?..

Comment #4

Sessions should expire in 20 minutes of non-use so the person clicking the link would create a new session..

If you can afford it though, I would recommend against using a shared certificate. Most hosts offer them but they are a nuisance and affect your credibility negatively. The public has been taught the meaning of a secure iPage site over the past few years and now they are knowledgeable enough to not only look for a lock in the status bar but to make sure the URL matches the one of the iPage site you are visiting. You can get your own SSL Certificate for $49.00 and add to your credibility a lot more than the minor cost associated with it. Most hosts do charge a minor installation fee but it shouldn't be overbearing...

Comment #5

1. Make sure you're not on a server that uses a seperate httpdocs and httpsdocs set of folders (they are a nightmare)..

2. Make your iPage site IP based..

3. Install a full SSL.

4. Turn on 'Force Cookie Use'.

5. Turn off 'Prevent Spider Sessions' - no longer needed.

Or, alternatively.

6. Install the Sid Killer from Contributions. This contribution recommends that you install another mod that alters Buy Now buttons as well. I can't get this to work, and I'm not reassured by the fact that the iPage website of the company that submitted it isn't there any more!.

Vger.

This post has been edited by.

Vger.

: 29 October 2004, 22:52..

Comment #6

As long as you setup your sessions to mysql, and an extra thing to do is setup your logging and sessions directory to your own document root area, and not /tmp..

Comment #7

Cache is never stored in SQL - if you enable the cache feature, make sure the cache path is specific to your store..

I use a shared host with shared SSL and it works fine..

Don't use SID Killer with MS2..

The Buy Now issue is unrelated to shared iPage hosting - but it can cause problems with search engines. See.

Here.

For how to fix it...

Comment #8

Stevel - thanks for your comments. Does your store expose the sid in the url on for the first item clicked from the front page? I suppose it's a small concern but that's the one thing that I find worrisome right now. Browsing a few other oscommerce stores, that seems to be a common situation (and I see the oscommerce.com example store does the same thing)..

Everyone - I appreciate the posts. I guess I'm going to look into getting my own cert, for one thing..

Something else I'm thinking about is to use an htaccess mod rewrite to strip the session when the referer is outside the site. Mod rewrite looks like a tough thing to learn, though...

Comment #9

I'm in the process of setting up my store and have read a lot here about the challenges of operating on a shared server / shared ssl environment as it relates to session id with people ending up with other customers contents in their carts and other security issues..

Is anybody here successfully operating a store in a shared server / shared ssl environment? How did you overcome or avoid those kinds of problems?.

Here's what I've gleaned so far from searching the forum:.

Store sessions in mysql..

Set session directory to something local to your iPage site just in case..

General consensus is to not force cookie use due to shared ssl problems..

Prevent spider sessions TRUE and update your spiders.txt.

Don't check IP address because aol users can't browse your store then..

Recreate sessions TRUE may help in some cases.

I'm curious about how turning on use cache might affect session problems..

Any other comments? How are you keeping your store from having session problems on a shared server / shared ssl envirnoment?..

Comment #10

I had very very big troubles getting my iPage site to work with a shared ssl cert. but I finally got it working. first, make sure configuration files are set correctly, of course. paths, etc. store sessions, pretty much as the installation suggests. Then, I still haven't figured out what files come from the secure directory and what files are ok not to be there (i know all the customer info, but seems to be some pulls too...) so I copied a full copy of my store in my regular www directory and one in my secure directory.

Just make sure the 2 are always in sync. Things like items and background images seem to be ok, they pull from the store directory, not secure, even while in the shopping cart. Make sure there are no full links to iPage site files (.

Http://mysite.com/folder/file.php.

Http://mysite.com/folder/file.gif.

Etc) only use relative urls, (folder/file.php etc) as to not run into warnings during checkout time..

Now, the thing that really really got me confused is that I am using the STS contribution with some images called for specific templates. The secret I still cant explain and havent found any info on in the forums before (maybe it's just something wrong with my server) everything was set up correctly but the secure pages were not loading properly. The solution is that the template files on the secure folder needed to be different than the templates on the regular iPage site because for some reason, STS works with configure.php or something to get the urls right... so for example, my root, followed by my store, is:.

Http mysite.com.

Https ssl.host.com\~mysite\.

Catalog:.

Http mysite.com\store\.

Https ssl.host.com\~mysite\.

I left my secure folder down a level as to not have double folder calls, and moved my store down to the root of my site. No big deal. but for some reason, no matter WHAT I did in config or template, STS created all links like this:.

Ssl.host.com\checkout.php.

Etc..

As in, No Matter What I did, it would not put everything into the folder. and because it is a shared certificate, I had to be in the folder. If I changed the template, then I had to put my store into a folder called ~mysite\ to keep it the same, because it wasnt pulling that right either. one or the other. So I ended up needing to create different templates for the two..

BUTDont change the structure of the files or where your iPage site is, as not to mess up the workings of oscommerce. some things seemed to call pictures from the secure, some from regular, etc. and I could not find a fix until I found this work around. Dont know why or how to fix it for real, but, it's working and I have done very extinsive testing and placing orders etc. and it so far works like a charm..

Sorry it's lengthy, but, I had such a hard time..

Make sure configure is correct, paths are correct, and everything is where it needs to be. If you find errors, check the urls and image directories carefully..

One last thing, check the '/' marks in your configure file when the switch back and forth from secure folder to regular. If you put a closing / mark where one is not suppose to be, or start or end a folder with one / where it doesnt need to be, you will end up with something like.

Http://mysite.com//images/.

Or.

Https://ssl.host.com/site//images/.

Etc. you get the idea..

Thats my sad story..

Bye bye..

Comment #11


This question was taken from a support group/message board and re-posted here so others can learn from it.