I upgraded to CF2018 from CF2016, running on a Windows 2016 Server with IIS. I am using subdomains. Example: A user logs into app.mydomain.com using cflogin and they click a button to create a batch of work to do. The button click launches an ajax remote call to job.mydomain.com to setup a job queue in the database sets a task in the CF Scheduler.
The scheduler launches the job page on job.mydomain.com that queries the job info. It knows what subdomain it was from and what user created it, so within a cfthread it executes a remote call to app.mydomain.com and does a cflogin allowconcurrent=true for the userid that was sent. This way it can know the permissions and whether this user can process it.
In CF 2016 it works great. Upon upgrading to CF 2018 it logs the user out as soon as the scheduler runs and does the cflogin within the thread.
Does anyone have any idea what might have changed from 2016 to 2018 that may have broken this? Or any ideas how I can implement so it will work again?
So I found that if I add a unique name to cflogin, then it works as desired. It is like the allowConcurrent stopped working. I will have to do some tests to see if that is correct or if something else is going on.
What do you mean by "add a unique name to cflogin"? What value do you use for the cookie domain attribute?
I guess it would be the
So when a user logs in it will log them in with their email address:
When the job queue runs it starts this thread (very basic example)
<cfthread><cflogin><cfloginuser name="email@example.com" permissions="x"></cflogin></cfthread>
But it would log the user that is logged in out with that same email address. I found that if I just added a unique value to the end of the email address then it would leave them logged in and do it's job.
That won't work as the job queue is a totally separate process run on the server and it sends a call to the other domain to run a certain chunk of a task or process. Each task sets up that user and the permissions so that it knows that they really have permission to do the task. Anyway, the getAuthUser would always be false. That is why it was so strange to see the problem. The client only executes a call to the other domain to let it know that it has an item in the queue to work on, but it starts immediately on it and then logs the client out because it made the call in the thread behind the scenes. It works totally fine on CF2016, but 2018 it didn't work on development or production, so something changed.
That won't work as the job queue is a totally separate process run on the server and it sends a call to the other domain to run a certain chunk of a task or process.
Hence suggestion 1), specifying the domain.
Anyway, the getAuthUser would always be false.
No. You apparently haven't tried the suggestion. Given the above details, getAuthUser() will return Email@email.com or "".
My guess is that ColdFusion's behaviour with regard to <cfthread><cflogin allowconcurrent="true"><cfloginuser /></cflogin><cfthread> wouldn't have changed between versions 2016 and 2018. What might have changed is the way ColdFusion reacts to code that is unpredictable or ambiguous.
This one is, in my opinion. After ColdFusion runs <cflogin><cfloginuser /></cflogin>, and logs the user in, it wont run those tags again until the user logs out.
Now, imagine this behaviour within the thread. So long as the user is logged in, the rest of the code within the thread will run, with the exception of the login tags. On the other hand, if the user is logged out, the code in the thread will run. So, whether or not the user is logged in, the code in the thread will still run. That is logic I don't understand. I expected something like:
if (user is logged in)
run thread code