my ongoing database permissions drama
Kay Smoljak
Summary: The user that Enterprise Manager *swears* is in the dbo role
on the live server does not have permission to query tables that
aren't qualified with the user name. As some parts of FarCry specify
the user before the table and some don't, some areas (eg handpicked
rule, some areas of user permissions, approving includes etc) no
longer work. My dev server which mimics their setup pretty closely -
same db username, even - does not have this problem.
What's happened now:
1) The sysadmin reowned all tables to a new user, removed the original
user, then readded the original user, set the newly-added-original
user to the dbo role, and then reowned all the tables back again. The
end result was that the problem was not resolved, it's exactly like it
was before.
2) To test, Kay decides to reown all tables on her working dev server
as "dbo" rather than the original user which was in the dbo role. The
test script, which attempts a straight cfquery without a fully
qualified table name, now works. She then changes FarCry's database
user in config\_serverSpecificVars.cfm to "dbo." and restarts IIS and
CF for good measure.
The result of this was that the (previously working) dev site appeared
to be working for a short while. I decided to test deploying a custom
rule to make sure that part was all still good and that the new tables
would have the correct user. I went into Admin->COAPI Admin->Rule
Class and got a big fat error message: Could not find the ColdFusion
Component rules. The front end of the site now starts throwing errors
about security so I reboot the server (it's a virtual machine and
sometimes a bit flaky). Now I can't even go to the home page of the
site without getting the "Could not find the ColdFusion Component
rules" error (listed in full below).
Help! Before I go and a) reown all the tables back to their original
config b) sacrifice a chicken, does anyone have any ideas for
salvaging the situation?
--
Kay Smoljak
http://kay.zombiecoder.com/
Kay Smoljak
What happened: the rule I was about to test deploy was what caused the
entire site to go down. I just grabbed any old thing from the local dev
dir and uploaded it. Obviously when I went to the COAPI section in the
FarCry admin, the system tried to parse the CFC which had god knows
what in it, and that fried the entire app.
Once I deleted the CFC from the custom rules directory, the site
started working again. I didn't even think to check that at first, as I
thought that only rules that had been deployed could cause that kind of
problem. Will definitely make a note of that one for future reference!
As for the database issue, I think reowning as dbo and changing
FarCry's database user accordingly will fix the issue on the live
server. I've done as much testing as is possible on the dev server and
I don't think it will cause any problems.
Thanks for listening, and hopefully this might help someone in the
archives one day, who knows :)
Geoff Bowers
>Update: All is now good.
>
>What happened: the rule I was about to test deploy was what caused the
>entire site to go down. I just grabbed any old thing from the local dev
>dir and uploaded it. Obviously when I went to the COAPI section in the
>FarCry admin, the system tried to parse the CFC which had god knows
>what in it, and that fried the entire app.
>
>Once I deleted the CFC from the custom rules directory, the site
>started working again. I didn't even think to check that at first, as I
>thought that only rules that had been deployed could cause that kind of
>problem. Will definitely make a note of that one for future reference!
>
>
Kay.. could you put in a feature request for this. Components that fail
to compile properly (or adhere to specific FarCry requirements) should
be ignored by the system rather than just causing general failure. It's
something I'd look to fix in 3.0.2
Thanks,
-- geoff
http://www.daemon.com.au/
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.
http://www.mailguard.com.au/mg