View Full Version : Store URL being redirected again
Deskdirect
1-4-05, 11:52 AM
I had this problem awhile ago and it resolved itself. But its back............. the store URL is http://www.mitchryder.com/store and it is redirected to https://mitchryder.secure.powweb.com/store/logoff.php?osCsid=10c526b872dca89397df2946f6fc2592 which comes up as a page not found error. It does reslove itself upon refreshing the page.
Help!
This is very, very strange...!
When I tried to visit your store I was first redirected to http://www.spiegel.de/ and only at the 2nd attempt I got to see your store. Then I cleared the browser cache, closed all browser windows, and it's the same thing again.
A view-source of the URL "http://www.mitchryder.com/store/index.php" is automatically forwarded to "http://www.http.com//mitchryder.com/store/?osCsid=" and this is the source:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
<title>SearchMachine.com</title>
<META NAME="Keywords" CONTENT="">
<META NAME="Description" CONTENT="">
<script language="JavaScript" src="http://www.registrarads.com/adpopup.php?n=a4327b18&what=zone:12&target=_blank& popunder=1&left=300&top=250"></script><script language="JavaScript" src="http://www.registrarads.com/adpopup.php?n=a4327b18&what=zone:12&target=_blank& popunder=1&left=300&top=250"></script><script language="JavaScript" src="http://www.registrarads.com/adpopup.php?n=a07d3b1b&what=zone:40&target=_blank& popunder=1&left=500&top=100"></script>
</head>
<frameset frameborder="0" framespacing="0" border="0" rows="100%,*">
<frame name="MYTOPFRAME" src="http://www.searchmachine.com/index-http.html" noresize>
<noframes>
<body>
<h1>SearchMachine.com</h1>
<br>
<br>
<br>
Click here to enter <a href="http://www.searchmachine.com/index-http.html">http://www.searchmachine.com/index-http.html</a>
<hr>
| Domain Name Registration and Domain Name Forwarding by <a href="http://www.mydomain.com">mydomain.com - Register your domain name</a>
</body>
</noframes>
</frameset>
</html>
But again, only at the first attempt, every ongoing attempt to open the URL ot to view the source will go to the index page of your store.
Clueless :confused:
Deskdirect
1-4-05, 02:46 PM
When I tried to visit your store I was first redirected to http://www.spiegel.de/
That is strange!
What's bothering me is that I have had several people complain that the store is off line (they didn't bother to refresh the page). I really need to figure this one out quickly.
Just an idea... Do you use file based session storage?
Using file based session storage on shared hosting servers may allow other users on the same server to access the session data stored in the files which opens the possibility for customer sessions to be hijacked.The work directory does not exist by default on new osCommerce installations as the directory should not be publicly accessible via a WWW address. It is important that this directory exists outside the webserver path and is used only for one osCommerce installation.Source: http://www.oscommerce.info/kb/osCommerce/Installing_osCommerce/16
Deskdirect
1-4-05, 03:33 PM
No I'm using mysql sessions.
The work directory does not exist by default on new osCommerce installations as the directory should not be publicly accessible via a WWW address. It is important that this directory exists outside the webserver path and is used only for one osCommerce installation.
I have no clue what the Work directory is or why that would be a problem as this store has been up and running for over 2 years.
If I disable (set to false) this line in the config files - define('ENABLE_SSL_CATALOG', 'true'); // secure webserver for catalog module - the url seems to resolve correctly.
The store index.php is being redirected by a file or something.........just can't seem to figure it out. Mybe its in my .htaccess file but I doubt it since the only thing I've changed lately in that file was to not allow viewing of my php.ini file.
Try this. Go to your registrar and fix the list of name servers to exclude the non-existent NS1.POWWEB.COM
Deskdirect
1-4-05, 08:46 PM
I removed NS1.POWWEB.COM.
Will I need to wait a few days to see if this clears up or should the change be immediate?
I expect that the effect of this should be seen sooner than later. But there is definitely something VERY odd with your store. When I try loading it, I am redirected to microsoft.com! (And I am using Firefox!) But only the first time I visit. I haven't yet figured out why, but if I had to guess, it would be something in your .htaccess. Post it.
Edit: I changed my mind - I don't see how it could be the .htaccess. But even more bizarre is that the page starts to load - I can see all the HTML - and then, only the first time, before any of the page displays except the title, it refreshes and heads off to microsoft.com! I don't know what could cause this.
Ok, now here's something curious. I decided to try opening the page in MSIE. MSIE complained that the page was trying to open a file on my "Intranet site" named "http" and did I want to allow this. I said no. Then I came to a blank page whose source was as follows:
<html><head><meta http-equiv="Refresh" content="0;URL=https://mitchryder.secure.powweb.com/store/logoff.php?osCsid=d1a9c0604fee434d29b97587f990ae2f "></head><body></body></html>
Do you have some sort of code that looks for a cookie and logs off people? If I cleared the mitchryder.com cookies, then the redirect behavior comes back, so now we know why it happens only the first time.
I'm guessing you have a bug in your auto-logoff code. Maybe those blanks at the end of the redirect URL?
Deskdirect
1-4-05, 11:21 PM
Steve,
I have a very basic store set up. I've made a few modification when I come across a contrib that I think would be of use to my store visitors.
I have no idea where the redirect code is coming from. And I don't have any sort of code that looks for a cookie and logs off people. This problem first come to light earlier this year with the whole trailing / situation. After a few weeks it went away.
I've don't know alot about php but I have checked for a redirect code in my .htaccess files, config files, etc. I've checked my meta tags file, header, logoff..........
I'm guessing you have a bug in your auto-logoff code. Maybe those blanks at the end of the redirect URL?
I certainly don't want to ask you to "actually do," but I haven't got a clue how or what to check to find a bug in my auto-logoff code. But I would appreciate it if you would point me in the right direction.
Thanks mucho!
Deskdirect
1-5-05, 01:27 AM
Another store owner suggested I set Auto-Login in the admin to false. I did and the store seems to been resolving fine. I tried to set it back to true for a test but it will not reset, so I must have goofed something else up but at this point that's the least of my worries.
You definitely have some redirect code in there. The "Auto-Login" feature you mention in admin is NOT standard - someone added it.
If you want me to take a look, send me a PM with your FTP server name, and an FTP username and password I can use to look around. I suspect that the auto-login feature you added has a bug in that it puts spaces at the end of the redirect URL.
Deskdirect
1-5-05, 12:05 PM
OK I managed to deal with the autologin code. Now my problem seems to be whenever I try to make admin changes it throws an error onto my index page.
Got any idea what I've done to cause the admin control panel to go wacky and not save any changes?
What error is displayed? My crystal ball is out for repairs. My offer to look at your site by FTP stands. Debugging this sort of thing without seeing the actual PHP code is difficult.
Deskdirect
1-5-05, 02:36 PM
Here is the error - sent you a PM
I attempted to change the way expected products were viewed.
1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'desc limit 10' at line 1
select p.products_id, pd.products_name, products_date_available as date_expected from products p, products_description pd where to_days(products_date_available) >= to_days(now()) and p.products_id = pd.products_id and pd.language_id = '1' order by desc limit 10
Ok. I'll have to study that to see what the problem is.
I sent you a long PM, but just to keep others informed. Your biggest problem is that the "configuration" table in the database is corrupted. There are a number of duplicate entries (which will make behavior of the store unpredictable) and some entries which have values in the wrong fields. This was probably caused by multiple SQL insertions from contributions, but they're not all identical in all regards (some have typos in the title field.)
Another problem is that whenever you update a value in your admin, whatever you entered gets stored as a null string. I couldn't figure out why that was happening. This caused your SQL query error. I could patch up values by hand using phpmyadmin, but that is not a solution.
Not very pretty...
Deskdirect
1-5-05, 10:20 PM
Thanks so very much!
I'll keep you posted.
Oh, this was very interesting... It turns out that the problem with the configuration editing (and indeed ANY form submission with POST variables) was due to this little bit of .htaccess code:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^mitchryder.com$
RewriteRule ^(.*)$ http://www.mitchryder.com/$1 [R=301,L]
I'll be honest and say I don't know why this causes a problem, but it does. (If I had to guess, and I'm not going to experiment further, I'd look at that R=301 flag which causes the browser to be sent a 301 permanent redirect response. This might cause the POSTDATA to be thrown away.)
Here's how I went about debugging this. First, I determined that the PHP file doing the processing was exactly the same as the osC 2.2-MS2 distribution. So it wasn't a code failure. I also determined that other pages in admin that submitted forms had the same problem.
So now I knew it was something global to the site. What is there? Hmm, a php.ini. But it looked pretty much the same as the one my store uses. What else? .htaccess! It had a lot of stuff in it, some I understood, some I didn't. I renamed .htaccess to something else and the site worked! So then it was a matter of elimination to find the offending lines.
This one sure was a head-scratcher. I feel much better for having figured it out - I hate it when I'm left with an "I don't know".
vBulletin v3.6.0, Copyright ©2000-2009, Jelsoft Enterprises Ltd.