Migrated to production server now I can't login as admin

[SteveHiner]

I moved from our beta.domain address to http://www.domain address, updated the license key and the site works except that when I try to login as the admin it never prompts me for the captcha and doesn't actually log me in. It returns me to the search page as an anonymous user. I'm wondering if there's something I can change in the database to get it fixed. Is there somewhere that associates the login with the beta.domain.com address so it's no good on the http://www.domain.com address?

The database didn't move since the SQL Server is accessible from both domains within our account.

I checked the error log table and there's nothing there and no error gets returned to the browser.

Any ideas?

[jmestep]

To trouble shoot, try putting demoMode=true into the first line of the ablecommerce.config file and see if you can log in as admin.
There is also an entry in the ac_StoreSettings table for the Store_StoreUrl. You might have to change that.

[ryanstowasser]

You can add a user as an admin through the database.

find the UserId from the ac_User Table.

find the GroupId you want to associate to it in the ac_Group table.

add a new record to ac_UserGroup with the UserId and GroupId you want to associate. done.

[AbleMods]

Is your SSL working?

Admin pages won't be display-able if they cannot render in HTTPS context.

[sdlong02]

I moved from our beta.domain address to http://www.domain address, updated the license key and the site works except that when I try to login as the admin it never prompts me for the captcha and doesn't actually log me in. It returns me to the search page as an anonymous user. I'm wondering if there's something I can change in the database to get it fixed. Is there somewhere that associates the login with the beta.domain.com address so it's no good on the http://www.domain.com address?

The database didn't move since the SQL Server is accessible from both domains within our account.

I checked the error log table and there's nothing there and no error gets returned to the browser.

Any ideas?

If you're hitting enter try clicking the login button instead.

[SteveHiner]

I tried the demomode switch but it didn't appear to do anything. Do I need to restart IIS to make that take effect? I don't think my ISP will let me recycle the ASP.Net worker process. I'm going to wait until tomorrow and see if it recycles on its own and picks up the change.

It is not running under SSL but the beta site let me use the admin pages even without SSL. Implementing SSL was actually the main reason we were moving it from beta to production.

I don't know if this is a clue or not but the beta site and production site have all the same files on them other than the license I think. They both use the same exact database since it's accessible from either one. The beta site's admin pages work fine, the production site's admin pages behave as described earlier. The production site seems to ignore login requests. It'll accept the userid and password but then doesn't give any error message but doesn't log me in either.

Any other ideas?

Sorry for the delay in responding to your replies - this has been a crazy week and I just now got a chance to try out the suggestions.

[mazhar]

Did you tried to login by clicking the login button after providing it credentials instead of hitting enter key?

[SteveHiner]

Did you tried to login by clicking the login button after providing it credentials instead of hitting enter key?

Good point and it revealed something.

Clicking Login doesn't do anything at all. It behaves as if that isn't a clickable button. The Register button on the same page does respond to clicks though.

[mazhar]

What is your browser information?

[SteveHiner]

Figured out what's causing it but I'm not sure how to solve it at the moment.

We host with Mosso.com. They allow you to select either Windows or Linux hosting environments by default but you can mix technologies so you can put aspx files on a site that is defaulted to Linux and they get fed to an IIS server for processing. Our beta site is set to default to Windows while the production site defaults to Linux because the current site is a static html and php site.

I believe the postbacks are trying to call back into login.aspx but the file system only has Login.aspx. I confirmed that this is part of the problem by loading the Login.aspx page then changing the filename to login.aspx through FTP and it allowed me to log in like normal. Unfortunately just leaving the file named login.aspx doesn't work since the pages all reference Login.aspx. I also tried putting both Login.aspx and login.aspx on the site but that doesn't work either - I'm guessing it somehow confuses IIS since they are actually separate files on the file system.

I realize there might not be a solution to this problem since this is a really unusual issue but I thought I'd post what I found just in case someone has an idea of how to work around it. I also wanted to make sure the issue is listed here in case someone else has a similar problem. Obviously, when we switch the production site over to the Able Commerce site we will also switch our hosting account to default to Windows hosting instead of Linux hosting.

[herchenx]

Have you resolved the issues with mosso? Is AbleCommerce running well on Mosso's cloud?

[SteveHiner]

Actually, I'm glad you wrote because I should update this post anyway. It turns out I was partially incorrect as to the cause of the problem. It is due to the mix of Linux+Apache vs Microsoft IIS, however it wasn't entirely caused by the case of the file names.

Using Fiddler2 (it's an HTTP debugging proxy, shows you all traffice between your system and the server) I was able to determine that the login screen was using javascript calls. Those javascript calls were to routines contained in virtual files managed by the script manager features of ASP.NET. ASP.NET manages the scripts by putting in links to virtual files on the server. For instance, you'll see references to the javascript source looking like this:
<script src="/WebResource.axd?d=86YQNY89tca_zcJetxWYfg2&t=633363112378379010" type="text/javascript"></script>
or this:
<script src="/ScriptResource.axd?d=lrQ2569SNiyT-bCBtCqcGHauoSbTfbc8nJZKNdeaRvNJlbWmUIX8XKy2ziC0NVL6SOwv4vGm3VnGUgXBGjVwEQ2&t=633363112378379010" type="text/javascript"></script>


The thing is WebResource.axd doesn't exist, it's a virtual file. When IIS sees that request come in, it will route the request to ASP.NET and it knows what scripts to send back in response to that request.

Now to Mosso. Mosso allows you to mix Linux hosted files with IIS hosted files. Normally this would be really cool because you can mix PHP files processed by Apache in the same folder as ASP.NET files processed by IIS. Seems like the best of both worlds. However, in this case by using Fiddler I found out that Apache was returning a 404 error for the .axd files. It appears their server was misinterpreting what it should do with virtual files. Normally it would pass any IIS file over to the Windows server but in this case, since the file wasn't there, it decided to handle the 404 error on its own.

After several online chat sessions with their tech support they finally elevated my issue to the network admins. Mysteriously the problem went away 2 or 3 days later. When I requested more details, in order to have info for the tech support if it happens again, I was told:

We're currently unable to reproduce the error here, but we were experiencing some temporary technical difficulties during that time.

Yeah, sure. After a couple weeks of having the problem and elevating it to the admins it just happened to correct itself.

Generally speaking I have had a really good experience with Mosso. Their tech support has always been really helpful - or at least they really seemed to want to help. They're always available quickly and are quite friendly. I don't want you to think they generally brush off their customer's questions but I am a little annoyed that they didn't "come clean" on the issue.

Other than the issue listed above Able seems to run quite well on Mosso's cloud. I did have an issue with getting the original install scripts to run. That problem was because Mosso actually stores the files on Linux boxes. By default, when you transfer text files to a Linux box using FTP it changes the line terminators from CrLf to just Cr (or is it just Lf?). Since the sql scripts the installer uses are text files they got converted. It turns out sql server doesn't like getting sql scripts with the wrong line terminators so it choked on them. Once I figured that out and uploaded the sql files in binary mode it installed just fine.

You should know though that they aren't the cheapest service to host with. They cost $100 a month (though you can host many sites in your account if you want - we have 5 or 6) and an additional $5 or $10 per month for a SQL Server database (depending on the size) plus an extra $20 (I think) per month for using an SSL certificate. I'm happy with the hosting but I'm not paying for it, my client is.

Hope this helps.

[herchenx]

SteveHiner, is mosso.com still working out for you? I just read that this hosting environment can't meet the requirements due to SSL and licensing issues, have you dealt with this at all?

Thanks in advance,

John