How can I let the kids use Webkinz with parental controls turned on?

Question

The kids like to play Webkinz. However, I enabled "Parental Controls" on their account, mainly so that I can limit their login hours—I haven't restricted the web sites they can visit using parental controls at all. It's an iMac running Leopard (we haven't "upgraded" to Snow Leopard, and don't plan to, unless it's guaranteed to fix this problem).

However, they can't play on the Webkinz web site from their account. Safari and Firefox both suffer the same fate: even when correct login info is provided, the application (which is Flash-based) responds that they can't log in.

From other accounts on the same machine, it works fine. From a PC, of course, it works fine.

I found some posts in other forums about the problem, but no real solutions.

How can I let the kids play Webkinz, while keeping parental controls turned on?

---

Update: When looking at /private/var/log/apache2/access_log, as suggested by cwrea, I see these two requests during login:

127.0.0.1 - - [21/Aug/2009:21:40:05 -0600] "POST http://66.48.69.102/login.php HTTP/1.1" 200 35 127.0.0.1 - - [21/Aug/2009:21:40:06 -0600] "oxy-Connection: keep-alive" 400 226

Note the invalid request: "oxy-Connection: keep-alive". Clearly, somehow the request is getting mangled, and only part of a request header is reaching the parent control proxy. Any ideas about what is causing this, or proxy-related settings for Flash?

Answer 1

If the parental controls you are referring to allow you to specify a list of sites that can always be accessed (what's known as a whitelist), then you likely need to add some additional host names or IP addresses to the permitted list to get Webkinz to work properly. Here's why:

Even though you may visibly be able to browse to the www.webkinz.com home page, the Flash application that gets downloaded to log you into the game actually uses other web servers behind the scenes to load game content (Flash SWFs, images, sounds, etc.) and to communicate with the servers that implement the game logic such as remembering what kind of pet you have, its name, inventory, etc.

Furthermore, large sites like that often use Content Delivery Networks (CDNs) to optimize bandwidth and scale to many concurrent users, so many host names or IP addresses are typically involved in the whitelist setup, even though in any given single session your browser might only use one of those addresses.

There's a Webkinz support page that lists the IP addresses that one needs to allow for the game to function. See: Webkinz World is being blocked by my Parental Control software - what do I do?.

Also, I came across this Apple Support Discussions thread which indicates a workaround may be necessary since Webkinz uses bare IP addresses and not host names for some of the servers it connects to. The workaround is to add those addresses to /etc/hosts.

I would guess that workaround is necessary since the parental controls logic probably wants to perform a reverse name lookup on any bare IP address, to make sure the site being accessed isn't actually one being restricted by host name. Otherwise, it would be possible for smart kids who knew a site's real IP address to bypass any restriction that used only the name!

Answer 2

Although the problem description is different, I found a post about a similar problem that suggested disabling the Parental Controls proxy server by removing its execute permissions. I tried it and—Webkinz is now working!

The command to do that, from a Terminal window, is

sudo chmod a-x /usr/sbin/httpd

This allows me to run Parental Controls without any web filtering, which is essentially what I want to do for now (using parental controls to limit login times). I will have to look into another solution for content filtering, as Leopard's built-in content filter is too buggy.

Looking for similar pages, I also found this article that suggested rather than disabling httpd, disable a different proxy called httpsproxyd. I haven't tried this yet (and I don't need to serve web content from this Mac right now), but it might be worth a try.

As noted in the article, one caveat is that the permissions might be reset by future system updates. If the kids start crying, I'll know where to look first.

---

Update

After installing Snow Leopard, the permissions on /usr/sbin/httpd were reset to be executable, but the problem seems to be gone. I guess the bug has been fixed, but I could never find the bug report, much less a description of the fix.