[closed] Can't log in to webtop on new 7.2.9 Chelsea Boots install

support
#1

Hello, I have set up a new install of 7.2.9 Chelsea Boots, using MySQL and CF2016. Install goes fine, and I can browse the site no problem. Going to http://mysite.org/farcry/core/webtop/login.cfm does take me to the login screen for Chelsea Boots, but when I try to enter base admin credentials (farcry/farcry), the login screen keeps refreshing. I do not get an incorrect password note or other error, but it never logs me in either.

I have tried ?updateall=newsite both on the main site index page as well as the login page, and it does reload the app, but I still cannot log in at the webtop.

User account is in the database and everything looks good. Any clues? Thanks in advance!

#2

This is usually cookie related, you might have either already had some
session cookies set on this url before, or perhaps domain cookies are
enabled and its trying to pick up cookie values from the root domain.

Clearing cookies (or individually removing the cfid, cftoken or jsessionid
cookies) using your browsers developer console should resolve it :slight_smile:

#3

LOL yep that did the trick; thanks so much! You are right, the new install is a test set up on a subdomain. Thanks for the tip!

1 Like
#4

Is there any more insight you can give on this. We’re trying to move a site from a windows hosting environment running adobe ColdFusion to a Linux container running lucee and nginx. For some reason, the farcry user is able to login without trouble, but most of our other legacy users aren’t able to successfully go into the webtop. For some reason, the login page just reloads. We’ve tried a lot of things in terms of clearing cookies, restarting lucee, updating farcry. What’s interesting is that in the farLog table, they look like successful logins and the farUser table doesn’t show “failedLogins”. The only thing that seems to be substantially different is that the ipaddress logged in farLog has an appended port number, which I think is a result of how our container is talking to the parent Azure Web App. Are there settings in config or farcryConstructor that we can tweak to have this thing look past any legacy cookies/session data that might be causing the problem?

#5

Is it possible that this problem is more pernicious on Chrome(ium) than Edge or Firefox?

#6

I have also seen this kind of pattern when the server is configured to use j2ee sessions instead of cfml sessions.

Blair

#7

In looking at the session values after login, for successful logins, the dmProfile Struct was created and added to the Session, but for unsuccessful logins, while the badmin value was changed to 1, the dmProfile struct was never created. So, we looked at trying to force the session.

We seem to have found a bit of success with the following:
A) adding to the FarCryConstructor
B) Setting up a utility file that will fire sessionInvalidate() for the user (they can hit this page as a start before going on to the webtop
C) Setting up a utility page that fires ApplicationStop() and then redirects to the webtop login.

It seems like doing all of these things will basically help flush out from the server any vestige of session values across the different domains/servers.© as a step may be overkill and I would only advise having it done by a developer and not generally available… but it’s a component of “shock and awe” that can reset your baseline pretty well.