How do widgets in Wookie get around same-origin restrictions for Ajax requests?¶
The Widget javascript object available to running widgets has a proxify() method for just this purpose. Proxify wraps the request in a call to a proxy server.
So:
widget.proxify("http://example.org/myservice/")
results in a URL like:
http://my.wookie.org/proxy?url=http://example.org/myservice/&api_key=myapikey
Shindig also uses the same method for OpenSocial applications, and has its own bundled proxy service.
Wookie lets you use either; see the widgetserver.properties configuration file. This contains instructions for specifying either no proxy, the Wookie service, or the Shindig one (assuming its available).
Wookie's bundled proxy servlet is a bit stricter than the one bundled in Shindig, as it only allows text, xml or json (not binary), and can also be controlled using a whitelist set up by the Wookie administrator and using W3C WARP.
Note: as widget.proxify() is not part of the W3C Widget Interface specification, to make your widget work properly in other W3C Widget engines you should always check the function exists before trying to call it.
How does localization work in Wookie?¶
Wookie implements the localization model described in the W3C Widgets: Packaging and Configuration specification. This means that Widgets contain "locale" folders for specific locales (eg. "/locales/et/index.html"), and Wookie will serve resources in matching locale folders in preference to generic resources. Wookie uses the 'locale' parameter of a request for a new widget as the preferred locale for resource requests; if this is absent then Wookie uses the server's default locale as picked up through system settings. We use ICU4J for all locale processing, including locating system defaults.
When I run Wookie in Tomcat I get a "java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)"¶
This problem occurs when the security manager is enabled in Tomcat, but without the proper permission assigned for Wookie. There is documentation that can help you define the security policy properly in section on Running Wookie.
Wookie throws a "java.lang.NoSuchMethodError:javax.servlet.ServletContext.getContextPath()" exception when I try to load a widget¶
This problem occurs in version of Apache Tomcat that do not support the current Servlet specification; to avoid this error update to Tomcat 6.0 or higher. See Issue WOOKIE-105 for more information
Why can't I add any widgets, either through the admin interface or by dropping them into the deploy folder?¶
One of the most common reasons for this is that the application doesn't have permission to write to the wookie/wservices directory, which is where Wookie expands widgets when they are uploaded. For example, if you are deploying Wookie on Tomcat, make sure webapps/wookie is owned by the tomcat user and not by root.
My widgets do not seem to be updating the preference data in wookie¶
This is a known issue. See Issue WOOKIE-44 for more information. This problem typically occurs when using Internet Explorer (version 8 and less). It is only flagged here as a warning because depending on how the widget calls the widget javascript API, you may or may not encounter a problem. In essence there are two ways of setting a preference in your widgets javascript implementation...
(1) widget.preferences.setItem("foo", "bar"); (2) widget.preferences.foo = "bar";
If your widget has been coded to only use method (1), there should not be a problem in Internet Explorer. However if your widget implementation uses method (2) or a combination of both, then you may experience unexpected results.
If you are experiencing this problem and you are using Internet Explorer (version 8 or less), then...
(1) update the javascript code to only use method (1) above in the affected widget OR (2) install Internet Explorer version 9, which should resolve the problem.
Other browsers should be unaffected by this issue.
Why when I update my widget and load it back onto wookie do I get two copies of my widget in the gallery?¶
If your widget does not have an id defined in the widget's config.xml file or the id is not a valid URI then wookie will load but not update your widget. If this is the case then (for the moment) you will need to manually remove the old version of the widget using wookie's admin page.
Why do I get a dialog box saying "session error" when I try to view my widget?¶
There is a known issue when using Tomcat 7.* with Wookie (see WOOKIE-222). Sometimes when a widget is actually loaded, a browser alert box sometimes appears informing the user of a "Session Error".
This is caused by the DWR library used by Wookie for Comet-based widgets handling HTTP-only cookies incorrectly; Tomcat 7 uses HTTP-only cookies as the default setting to prevent cross-site scripting (XSS) attacks.
A workaround is to add the following to the WEB-INF/web.xml file
<init-param> <param-name>crossDomainSessionSecurity</param-name> <param-value>false</param-value> </init-param>
Note that XSS prevention will still be in place in Tomcat 7; this just disables the additional mechanism implemented in DWR that conflicts with it.
This is an issue for DWR 2. with Tomcat 7. (or earlier versions of Tomcat where useHttpOnly="true" is set.)
To set this to false for tomcat 7 you can add this to the context definition for wookie. This is found in
TOMCAT-ROOT/conf/Catalina/localhost/wookie.xml
The first line of xml needs to look like this
<Context crossContext="true" useHttpOnly="false">
Can I run Wookie from a USB drive?¶
Yes, more information can be found here.