jQuery fancybox ‘*.support not defined’ or ‘b.support not defined’ Error
I was importing some code from static HTML pages into a client’s home grown CMS system this morning. When I reviewed the site in Firefox with Firebug running, I was seeing the error:
b.support not defined
The site uses Fancybox to display the window overlays within the site so I had to step through the code and to find out what broke during the migration. Turns out it was a stupid mistake on my part.
Make sure that you include a reference to the jquery library before you load fancybox.
<script type="text/javascript" src="/js/jquery.min.js"></script> <script type="text/javascript" src="/js/Fancybox.js"></script>
Drobo Dashboard Can’t Connect to Drobo when ESET Firewall is Active
Have a Drobo storage unit? If you have ESET Smart Security Firewall enabled, you’ll probably find Drobo Dashboard can’t connect while the firewall is on even after adding all the required ports and services to ESET’s rules from the Drobo online help site (http://goo.gl/iVKVU).
After enabling the detailed logging in ESET, I found that ESET’s firewall was flagging Drobo Dashboard as an intrusion attempt and blocked it. From the Drobo help page (http://goo.gl/iVKVU):
Drobo Dashboard connects to port 5000 and then randomly picks a port in the range for broadcasting.
This is definitely not the most intelligent way to build a product when users who are trying to secure their home or business network and it’s no wonder that ESET flagged the behavior as suspicious. Luckily there’s a fix to keep ESET from blocking the Drobo connection:
- Make sure you add the rules as per Drobo’s site (http://goo.gl/iVKVU).
- Open the main program window by clicking ‘Start’ -> ‘All Programs’ -> ‘ESET’ -> ‘ESET Smart Security’.
- Click on ‘Setup’ on the left, and then click ‘Enter Advanced setup’ on the right to open the Advanced Setup tree.
- From the Advanced Setup tree on the left, Expand ‘Network’, and Click on ‘Personal Firewall’, and then select ‘Interactive mode’ from the Filtering mode drop-down menu on the right.
- From the advanced setup tree, click ‘Personal Firewall’ -> ‘Rules and zones’. Click the ‘Setup…’ button in the Trusted zone section and then choose ‘Allow sharing’. Click ‘OK’.
- Click ‘Personal Firewall’ -> ‘IDS and advanced options’. In the ‘Allowed services’ section, make sure all services are selected. Click ‘OK’.
Drobo Dashboard should now be able to connect to the unit with no issues.
SSL, jQuery, and CDN
I just got whacked by a minor bug with SSL and the Google CDN (totally my fault, not theirs). I stuck the reference to the CDN in my master page not realizing one of the pages would be served up as secured by the vendor due to compliance issues. It made it through all testing because none of the staging/dev environments were configured for SSL and I was not made aware of the fact that we’d be serving the page up through SSL. Internet Explorer 8 prompted users about the insecure content before rendering the page. In their infinite wisdom, Microsoft decided to implement a new workflow for insecure content where the content is ignored and the page renders immediately with the unsecured content ignored. Since jQuery was used on multiple parts of the form, the site essentially broke. Google Chrome and Firefox seem to recognize the CDN as a trusted source and render the page as expected.
To fix the site, I added a javascript check to set the appropriate prefix to the CDN call:
<script>// <![CDATA[
var gaJsHost = (("https:" == document.location.protocol) ? "https://" : "http://");
document.write(unescape("%3Cscript src='" + gaJsHost + "ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js' type='text/javascript'%3E%3C/script%3E"));
// ]]></script>
SQL 2008 DTSX
The Problem
Earlier today, I was working on setting up DTSX so some end users could run some packages. After loading and testing the packages successfully, the users tried running the package and encountered an interesting error:
SSIS Execution Properties
Failed to open package file “C:\Program Files\Microsoft SQL Server\100\DTS\Packages\dts_filename.dtsx” due to error 0x80070005 “Access is denied.”. This happens when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of either providing an incorrect file name was specified when calling LoadPackage or the XML file was specified and has an incorrect format. ({FFEE8F2F-A0A6-40BE-8CDA-86BEC124F874})
The packages were provided by another vendor so I wasn’t keen on trying to modify things within the packages themselves. I was able to run the packages under my admin account but the end users kept running into the error which lead me to believe that the user needed some special permissions. The users were connecting to this virtual server via remote desktop. While it was a dedicated virtual machine specifically for this project, I really didn’t want to give users admin rights because…well I don’t think that needs to be explained so I hunted around and of course there are no settings for controlling access via permissions in management studio. It was time to take to the interwebs and use my Google-Fu and see what others have found on this error. I found others who had similar errors but none had the exact issue. Some similar errors:
- http://msdn.microsoft.com/en-us/library/aa337083.aspx – This was the closest except that it dealt with remote access which wasn’t the case here. I tried it anyways in case it was the problem.
- http://www.mssqltips.com/tip.asp?tip=1199 – Proxy permissions for SQL agent which is useful to know when creating scheduled jobs.
The Solution
I remembered that SQL Management Studio had issues with accessing files in different locations (i.e. My Documents). With the new security settings in Windows, you may have noticed you need admin rights to add, run, or or modify folders/files in locations like c:\Program Files in Windows 7/2008. I wondered if DTSX used a special permission that allowed it to access files and checked the groups under the Server Manager. I found a group called SQLServerDTSUser$[MachineName]. I added the users who were executing the packages to this group and then checked the permissions on the folder C:\Program Files\Microsoft SQL Server\100\DTS which didn’t have the group listed. I added the group to the folder permissions, tested the package and voila – it worked.