Curious behavior?

[mugitty]

Just to set the scene, I encountered this because of some problems I was having getting rid of session IDs. The SIDKiller contrib by Ian works great and I am now convinced that the problem has nothing to do with that mod.

 

There are 6 different ways someone can reach the index page of my catalog (to avoid accusations of spamming or self-serving promotion, I am using a generic 'sitename' here :wink: - if someone wants to try what I'm describing, my WWW button will get you to the root. I'd also be interested if people were to try on their own sites to see if they get the same result.):

 

1) http://sitename/catalog

2) http://sitename/catalog/

3) http://sitename/catalog/index.php

4) http://www.sitename/catalog

5) http://www.sitename/catalog/

6) http://www.sitename/catalog/index.php

 

If I enter via numbers 1, 4, 5 or 6, I can go immediately to login with nothing in the cart and will be allowed to log in.

 

If I enter via number 2 or 3, the catalog will not allow me to log in unless I first add an item to my visitor's cart, after which I can log in without problem.

 

Numbers 2 and 3 when resolving to the browser do not end up showing 'www' in the address, but the other 4 do (including #1 which starts out without 'www' when typed into the browser address bar).

 

Can anyone explain to me what causes this peculiar behavior?

[Ajeh]

Are you defined in the configure.php files as http://www.sitename.com or as http://sitename.com

 

Set them to http://www.sitename.com and see if that fixes things.

 

Then check if you are using $DOCUMENT_ROOT or your real path.

[mugitty]

Linda;

 

Thanks for your response.

 

When you say

Set them to http://www.sitename.com and see if that fixes things.

do you mean all 3 instances?

in admin:

define('HTTP_SERVER', 'http://farmex.now.tc');

define('HTTP_CATALOG_SERVER', 'http://farmex.now.tc');

and in catalog:

define('HTTP_SERVER', 'http://farmex.now.tc');

because when I set all 3 of those to 'www', I can't log in in any of the 6 scenarios.

 

Also, where is the reference to

Then check if you are using $DOCUMENT_ROOT or your real path.

would that be in the configure files also?

[Ajeh]

Yes those are the settings.

 

I'd have to see the rest of your configure.php to see why it would not work with the full path.

 

Mine look like this:

  define('HTTP_SERVER', 'http://www.mylinkto.com'); // eg, http://localhost - should not be NULL for productive servers

 define('HTTPS_SERVER', 'https://secure.sashbox.net/~mylinkto'); // eg, https://localhost - should not be NULL for productive servers

 define('ENABLE_SSL', true); // secure webserver for checkout procedure?

 define('DIR_WS_CATALOG', '/osc_current/'); // absolute path required

 define('DIR_WS_IMAGES', 'images/');

 define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');

 define('DIR_WS_INCLUDES', 'includes/'); // If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), this can be a URL instead of a local pathname

 define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');

 define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');

 define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');

 define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');

 define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');



 define('DIR_WS_DOWNLOAD_PUBLIC', DIR_WS_CATALOG . 'pub/');

//  define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)

 define('DIR_FS_DOCUMENT_ROOT', '/home/mylinkto/public_html'); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)

 define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);

 define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');

 define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

[mugitty]

Linda;

 

Still no change. As near as I can tell, my catalog config is the same as yours

  define('HTTP_SERVER', 'http://farmex.now.tc'); // eg, http://localhost - should not be NULL for productive servers

 define('HTTPS_SERVER', 'https://secure14.vosn.net/~farmex'); // eg, https://localhost - should not be NULL for productive servers

 define('ENABLE_SSL', true); // secure webserver for checkout procedure?

 define('DIR_WS_CATALOG', '/catalog/'); // absolute path required

 define('DIR_WS_IMAGES', 'images/');

 define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');

 define('DIR_WS_INCLUDES', 'includes/'); // If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), this can be a URL instead of a local pathname

 define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');

 define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');

 define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');

 define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');

 define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');



 define('DIR_WS_DOWNLOAD_PUBLIC', DIR_WS_CATALOG . 'pub/');

 define('DIR_FS_DOCUMENT_ROOT', '/home/farmex/public_html');

 define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);

 define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');

 define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

I previously had

define('DIR_FS_CATALOG', '/home/farmex/public_html/catalog/');

and changed it to what yours is like

define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);

but that didn't change any of the behavior.

[Ajeh]

Do you have a .htaccess file that might be conflicting with the settings?

[mugitty]

This is the sum total of what's in my .htaccess file at root

ErrorDocument 400 /catalog/http_error.php?error_id=400

ErrorDocument 401 /catalog/http_error.php?error_id=401

ErrorDocument 403 /catalog/http_error.php?error_id=403

ErrorDocument 404 /catalog/http_error.php?error_id=404

ErrorDocument 405 /catalog/http_error.php?error_id=405

ErrorDocument 408 /catalog/http_error.php?error_id=408

ErrorDocument 415 /catalog/http_error.php?error_id=415

ErrorDocument 500 /catalog/http_error.php?error_id=500

ErrorDocument 501 /catalog/http_error.php?error_id=501

ErrorDocument 502 /catalog/http_error.php?error_id=502

ErrorDocument 503 /catalog/http_error.php?error_id=503

ErrorDocument 505 /catalog/http_error.php?error_id=505

ErrorDocument 504 /catalog/http_error.php?error_id=504

and at the catalog directory

<IfModule mod_setenvif.c>

 <IfDefine SSL>

   SetEnvIf User-Agent ".*MSIE.*" 

            nokeepalive ssl-unclean-shutdown 

            downgrade-1.0 force-response-1.0

 </IfDefine>

</IfModule>

and at the includes directory

<Files *.php>

Order Deny,Allow

Deny from all

</Files>

:?:

[Ajeh]

Try adding the www on your http:// and https:// settings

 

You site appears to toss you back and forth between those.

[mugitty]

Tried that previously. As soon as I add 'www' to the https settings, the pages quit resolving completely and I get the standard Windows error page (I don't even get my custom error pages).

[Ramesh]

Hi,

 

What about your httpd.conf

(The config file for your unix server)

 

it has lines like this:

 

<VirtualHost mysite.com www.mysite.com>

ServerName www.mysite.com

DocumentRoot /www/vhtdocs/mysite

</VirtualHost>

 

Has it not ?

 

Could that be it ?

 

I'm not sure, just trying to help .

[mugitty]

I really do appreciate all of the suggestions, but I want to be sure that we're not losing sight of the problem:

1) http://sitename/catalog

2) http://sitename/catalog/

3) http://sitename/catalog/index.php

4) http://www.sitename/catalog

5) http://www.sitename/catalog/

6) http://www.sitename/catalog/index.php

The problem being that everything is hunky-dory EXCEPT in case 2 and 3 where, if one tries to login after entering the index page via either of those addresses, the cart will not allow login unless you first add an item to the shopping cart.

[Daemonj]

Also keep in mind that IE does not display error pages if they are under a certain size (cannot remember the exact number right now).

 

Try adding a lot of extra text to one of your error pages and then cause the error to see if your page now appears. If it does you know that your stuff is working correctly and IE was just bypassing you.

 

HTH :)

[Ian]

Actually httpd.conf might be the problem. I do remember someone else having a similar problem and it was down to the re-write rules in httpd.conf.

 

There was a simple fix for it but I would have to do some digging to find it.

[Ian]

Memory getting less fuzzy, something to do with setting usecanonicalname to true, in httpd.conf.

 

I think it was David Garcia Watkins who told me what to do. I'll ask him again.

[Ian]

Ok, I think I'm with this now.

 

When Apache receives a URL it must make sure that the URL is fully formed. So if you type in http://mydomain.com without a trailing / apache wants to add the / to the end.

 

It uses some rules as to how the new URL is created.

 

In your case servername must be www.domain.com and useCanonicalname is on.

 

So for each of your different url's

 

1. Missing trailing /. Apache rewrites URL, but uses servername

2. No URL re-write needed URL does not change

3. As 2

4. Missing trailing /. Apache rewrites URL, but uses servername(which already has www)

5. No change

6. No change.

 

How to fix. Depends. Do you have access to your httpd.conf?

[mugitty]

Thanks for your efforts, Ian.

 

No, I'm on a shared server and don't have access to httpd

I can create .htpassword and .htaccess files and can always email customer support for a change in httpd as long as it doesn't adversely affect performance or other users on the server.

 

Are you saying it is this that is making the difference between being able to login without an item in the cart vs with an item in the cart in just these 2 instances (#2 and 3)?

 

I also thought that I had full "whatever-you-call-it" that the server sees (or at least resolves) "http://www.domain.com" the same as it sees "http://domain.com", but I could be mistaken.

[Guest]

Stuart,

 

Just for grins and giggles....Try adding the "www" to your HTTP address in the configure.php and see what that does.....Don't add it to the HTTPS this time.

[mugitty]

Thanks, Kim

 

I tried that the first go 'round and I believe all that did was not let me login in any of the 6 situations unless I had an item in the cart first.

[Ramesh]

so I was right, it was down to httpd.conf !

 

in order for both www.yourname.com and yourname.com to resolve,

they have to defined.

 

Sometimes your web management control panel will be able to do it.

 

You can enter your default filenames:

 

index.htm index.html index.php default.htm e.t.c

 

so when i visit www.yoursite.com , the server will feed one of these named files or return a error page if none exist.

 

For all other cases its down to httpd.conf.

 

I never lost sight of your problem,

I understood what you were saying 100 %.

 

when you have a problem , you need someone to bounce ideas off.

Thats whats great about forums.

 

You can discuss and go off at an angle.

I never suggest the obvious, I will always try and suggest something different.

 

Regards,

 

Ramesh.

native-english speaker

London.

[mugitty]

OK, I'll admit that I'm totally at sea with httpd.conf and exactly what it does.

 

How do settings in that make the difference between being able to login or not depending on whether there's an item in the shopping cart?

 

The index page can be accessed just fine in all 6 scenarios, it's just that 2 of them require an item in the cart before allowing login :?:

[Ian]

Stuart,

 

I'm probably talking out of my backside here, but as I said earlier I'm going off something I remember from a long time ago where someone had a similar problem.

 

It may be all down to how your servername is defined. It would appear from the way the url's are re-written when you miss the / that the servername is www.sitename.ext

 

This is somehow confusing the session storage. I just don't know why. I'm also suprised that if you change the HTTP_SERVER define to www.sitename.ext that you can't login at all.

 

A phpinfo page would come in happy here. PM me the page name if you don't want to give your secrets away.

[mugitty]

Well, I wrote to my hosting provider about this and they wrote back:

Hi Stuart,  

 

the easiest and quickest solution would be for you to decide which URL will be used to access the OScommerce store. Therefore if you find some URLs do not work correctly do not link to them.  

 

As for the URLs that have no trailing forward slash, this is standard apache behaviour. For example, a URL with no trailing forward slash is not a valid URL therefore your browser queries the server and apache returns the correct URL which your browser then redirects to. This is why you find the www prepended to the URL and the trailing forward slash appended.  

 

Please reopen this ticket authorizing charges if you wish to continue to troubleshoot the login issue. Please include an account username/password we can use to test with. If the problem is found to be a server issue no charges will apply :)

I am hesitant to go further with them, as I don't really have confidence that it is a server issue (I did mention httpd configuration in my note to them and they don't refer to it at all in their response).

 

So, for the time, I am running OK and as long as someone doesn't try to enter the catalog using method #2 or #3 as mentioned earlier in this thread. I can certainly eliminate 99% of that possibility by just not referring to those methods in any links that I use, but I'm still REAL curious as to why this behavior takes place.

 

Thanks for everyone's input and suggestions :D

[Ian]

Stuart,

 

i checked the phpinfo and the sever name is always with the www on the front.

 

As to your hosts reply. This is exactly what I thought. The simple solution is to have an apache rewrite rule which turns all http://sitename.com into http://www.sitename.com.

 

Whether your host will do this free gratis is another question.

[mugitty]

Thanks, Ian.

 

I think I'm just going to let it ride for now. If I get any customer comments about the issue, I'll get back with the host to do what you suggested.

 

:wink: