Until I installed OS X 10.6.5 update last night.
Safari under 10.6.5 does not handle cookies stored against IP addresses in the same way anymore, presumably as a side effect of a cookie-related security “fix”.
So to state it simply, if you have a web app that sets a cookie with the Domain attribute set to an IP address, this cookie will be stored but never sent to your server. What appears to happen is that cookies without a domain set e.g. JSESSIONID set by Tomcat, are successfully stored against the IP.
However as soon as you include domain= in your Set-Cookie header, this is stored with a “.” at the start of the domain in the browser cookie list (even if you didn’t put a “.” at the start of your domain) and it is then never sent to the server on subsequent requests.
The workaround is to update your code to not set the domain to the IP address of your host, but to the local host name. This is not normally a problem except when you are using a development tool locally.
By changing your code to use the bonjour name of the local host e.g. “marcmacbook.local” the problem goes away again – provided you browse to marcmacbook.local to test your site.
Something tells me this is a regression in OS X, not a deliberate change relating to the CFNetwork security bug.
Users and particularly developers of Palm’s old line of PalmOS devices will keenly remember that Palm were the only people to get syncing right at the time.
Aside from all the basics, they allowed 3rd party applications on the device AND the desktop to talk to each other directly to sync custom data. I’ve bitched about this before.
As an avid Mac, iPhone, MobileMe and soon to be iPad user, I have to wonder what is happening with this at Apple. My real-world gripe is this:
I was just about to open OmniFocus on my iPhone specifically so that it would sync with the latest data on my MacBook Pro, which is set to sync via MobileMe (using a pretty ugly file based solution). Why am I even doing this? Why isn’t this data synced (a) when I dock my iPhone to sync all the other iTunes stuff, and (b) why can’t it automatically sync wirelessly
Well part (b) is easier to answer, although it is a three-fold answer. First, there’s no background app support to allow automatic sync of the OmniFocus app on the phone. That should be addressed by the Push API functionality except that OmniFocus doesn’t support Push API (server cost to them to do so) and even if they did support Push, iPhone SDK Push is not able to automatically pass the data to the application to force it to sync – the user must acknowledge the event and run the app on the phone manually. It’s a pile of suck, surprisingly, with a real feel of “disconnected device”.
Part (a) is more tricky to answer. It must be trivial for Apple to add this kind of support for direct-to-app syncing. They already have/had Sync APIs for OS X for a long time. Lack of support for this apparently makes no sense.
In conclusion I am very surprised that Apple has not updated the OS X Sync APIs so that:
- Third party apps can sync any data they like to/from the iPhone/iPod/iPad with iTunes as the conduit (that was the concept’s name in PalmOS if I recall)
- The transport for sync is completely hidden from the applications such that sync will happen transparently via Dock, Wifi (direct between devices on local Wifi network), and via MobileMe cloud if the device is not on the same Wifi network.
This is not rocket science after all. And yet we still have to know / think about what networks our devices are connected to, manually make sure we run them frequently etc. It is pretty lame, Mr. Jobs.
I find it hard to imagine we will be plugging away at these cumbersome computers for that much longer, at least not for casual usage.
It is noticeable that Mac OS X and related apps are moving to user interface paradigms that will work much better than conventional UIs on (touch controlled?) TVs and multi-touch tablets.
Some examples of this growing trend:
- Front row started it really
- Several Apple apps with full screen modes. Especially the new quicktime X and its large transport buttons, iTunes/Front row with Coverflow, iPhoto with multitouch trackpad support
- The new exposé screen layout, touchpad gesture and per-app exposé
- Spaces – something that will prove MUCH more useful if every application is full screen, and effectively each Space is a single Application. Then Exposé sort of becomes the current spaces “zoom out”
- Safari “Top sites” is, in my opinion, clearly targetted at touch (tablet) displays.
- iTunes LP media format
- This is the big one – iTunes “Home Sharing”. This is required to solve the problem of your TV/tablet as a media purchase platform. You will typically buy content at home on a TV/tablet and then expect it to be on your laptop and hence iPod.
So I expect, within a few years, for us to see a new paradigm at least for TV and tablets where apps run full screen and you swipe to switch application… and wonderfully simple UIs as a result.
If we can only do away with the keyboard, we might finally be rid of these rather old fashioned apps with lots of menus and shortcuts and yada yada.
It is the little flourishes, flashes of beauty, or pleasant surprises that make life great. Like a beautifully struck cymbal that sticks out at you from within a song, I noticed a little touch in OS X Leopard for the first time today. I downloaded a .ICS calendar event file for the forthcoming Grails “Twitter in 40 minutes” Webinar, and noticed in my dock the icon for it:
Not only does the event file’s thumbnail show the month and day, it also shows a summary of the text and the start and end time, all beautifully rendered. A lot of effort will have gone into make this rendering look great, even though you may only see it a few times a year, if that.
That’s attention to detail, based on the understanding that the little things make a difference.