Client Storage in SQL Datasource suddenly fails

[ufitzi]

After performing several Windows 2008 security updates last night, one of the sites began throwing errors related to accessing the client storage datasource, which is the default as defined by the CF admin:
coldfusion.runtime.ClientScopeDBException: Operation failed on the DATASOURCE NAME data source.
Reason of failure java.security.AccessControlException: access denied.

Most of our sites are using this datasource for client storage, and none of them are having the issue.
Modifying the Application.cfm file to use clientstorage="cookie" got the site back up.
I then added a NEW datasource to the Client Storage list, and set the Application.cfm file to use it instead.
That works. As sson as I remove the clientstorage attribute from the Application.cfm file, the site breaks.
Short of restarting the server (which did happen last night after updates) I've restarted all IIS related services.
Any ideas??

[Daverms]

Hi,

Did you change your settings in the CFAdmin -> Server Settings -> Client Variables -> Storage to "Cookies",

Or else, if you already had any db kinda storage then try mapping your db location.

But, if you opt "cookies" storage, then make sure that you are updating all of your <cflocation> tag's addtoken attribute accordingly.

[ufitzi]

No, the default client storage remains the same.
I used the Application.cfm file for this particular site to override the default and use the new datasource I added this AM.

[Daverms]

Ok.. I presume after creating the "datasource_name" you removed the "clientstorage=cookies" entry (which you initially modified) from the Application.cfm.

And if I am right with the above statement, You should actually replace the clientstroage attribute of your cfapplication tag with the newly created datasource_name.

HTH

[ufitzi]

The original problem still exists. This one site cannot use the default client storage datasource, which EVERY OTHER SITE on this server uses. I've got the site up and running by using the new datasource to store the client vars, but that doesn't explain why this one site can't use the default data storage method.

[ufitzi]

A restart of the server DID NOT fix the issue.

[Charlie Arehart]

Ufitzi, here's my take on the situation. I have some background info (to make sure we're on the same page) and then something for you to try that may really help with your problem.

You had said, "As soon as I remove the clientstorage attribute from the Application.cfm file, the site breaks." That would be because the CF Admin is still set to use the old DSN as the default. The admin page on client variables has 2 purposes: to let you define DSNs to server as client var repositories, and to name which should be the default if code doesn't set it itself (like you did when you set the clientstorage attribute).

So you did step 1, added a new DSN. Then you skipped step 2 (set it as the default) and used code instead to set the clientstorage, first to use cookies, then to use the new DSN. When you removed it, you went back to using the old DSN, as it's still set as the default.

You could finish step 2, telling the Admin to use the new DSN as the default client storage. That should make the one (and all) apps work.

But your concern that "only 1 app breaks" using the old DSN is indeed curious. There's little reason for that. They would all access the DSN the same way, if all on the same server and using the same DSN for their client storage repository. I would challenge you to test to make SURE that the "other" apps really don't have their own clientstorage defined. It sure sounds like they do, and that they're not using the "bad" old one.

It can be tough to confirm, because a number of things could throw you off. First, the apps may be using application.cfc, rather than application.cfm. In that case, the latter is ignored and you have to look in the application.cfc for what's really controlling things. Second. either way, the code could be including (or invoking) another application.cfm or .cfc after the code you see that's setting (or not) the clientstorage attribute. You need to be sure you have confirmed that's not the case.

But here's some good news: there's no documented to confirm what a given app is using for its clientstorage, but there is an unsupported way:

<cfdump var="#Client.getPersistSettings().get("clientstorage")#">

Of course, that needs to be run in the scope of whatever app whose client storage you are trying to check. Be careful about mistakenly running it in some test directory outside of the app's.

Let us know if any of this helps.

[ufitzi]

Charlie,
Your review is correct....however, I intentionally left the default storage as was, since it did not seem to be affecting any other sites. I've confirmed the stability of all other sites using client variables. None are overriding the default storage datasource. Right now, the affected site is the only site storing client vars in a separate location, and it's functioning fine.
A colleague just had an interesting suggestion....we established a NEW datasource in CF admin, and pointed it to the same database as the default, and added it to the Client Storage list. We then set the site to use the new storage datasource, and it DID NOT work. Same error as before. I also changed the "name" attribute within the <cfapplication> tag, as this value is used in the CDATA table, but this also failed to solve the problem.
Starting to wonder if there is corrupt data in the CDATA/CGLOBAL tables?? My next step is to clear the client data associated with this site.

[Charlie Arehart]

Ufitzi, you say "I intentionally left the default storage as was, since it did not seem to be affecting any other sites."

Well, right, that's what I confirmed above. I noted that you had not changed the default, but only tested it as the clientstorage for a given app, and it failed. You go on to say, "I've confirmed the stability of all other sites using client variables", but my point was that you seem to have said that you're asserting that these other sites use the same clientstorage. How do you know, for sure?

You seemed to be saying that a given DSN works for one app, and not for another. That just seems unusual. (As you note, there's that one hitch that the app name is used for the cdata. I would have asked what was the value of the appname when the app was failing, but you're saying you tried changing it, and I'll assume to a reasonable value, and you say it still fails.)

So anyway, I was proposing that you run the simple little single line of code in the WORKING app/sites, to confirm that they are indeed using the DSN that you think they are. Seems worth double-checking, since you think they work with a DSN where another app fails. Let's just confirm that, rather than trust it from eyeballing the code.

As always, just trying to help.

[ufitzi]

I did run your code. It confirmed the client storage as the default.
I also double checked the Application.cfm files on all the sites.
They are all using the default client storage location, the MSSQL datasource.
So, only this one site throws the JAVA security error.
I'm going try purging the client data.
Thanks for your input!

[Charlie Arehart · Accepted solution]

Java security error, eh? You know, I'd missed that in your first note. (He said it was, "Reason of failure java.security.AccessControlException: access denied".)

I'm starting to wonder now: is this an Enterprise deployment of CF? Is it configured (in the CF Admin) to use what's called "Sandbox security"? If so, the problem could be that this one app is in a sandbox which has not been configured to access that DSN. Sandboxes are configured for all code running in a given directory (and its subdirectories), which would explain it working for all but this one.

Purging the client data is pretty drastic, if the data is important to your app. I'd recommend trying this if you have even just a little more time.

If you are anyone reading this would like to learn more about Sandbox Security, besides the docs you can read more in some articles I did for the Dev Center some years ago, at http://www.adobe.com/devnet/security/articles/sandbox_01.html and http://www.adobe.com/devnet/security/articles/sandbox_02.html. While it was written in the CF6 timeframe, it still applies in 7 and 8.

[ufitzi]

THAT'S IT!!
Good call, man...I can't believe I didn't check that.
Many thanks for your insight, mystery solved!

As a note, this problem WAS created after a Windows 2008 update.
I can't remember if I'd had the client datasource applied to the sandbox or not.
Thanks again!

[Charlie Arehart]

Glad I could help, Ufitzi. Thanks for the update.