Troubleshooting OSX Mavericks password problems

Before Christmas I enabled iCloud KeyChain, and it worked ok.
After the well deserved x-mas break (I didnt even open the lid of my work MacBook Pro for weeks), I started experiencing problems with Keychain access.

After a few days I got irritated when I noticed that applications where not able to access the stored passwords from the Keychain. 
As an example:

• Chrome no longer autofills my password when logging in to gmail
• Microsoft Remote Desktop failed to load/store passwords
• etc

Most disturbing was that when I tried to Add a new password to the login keychain directly, this failed with the message "you failed to provide the necessary administrator authorization"

I first thought the problem was related to iCloud Keychain, but this proved not to be the case. I found out that iCloud Keychain only is used by apple programs, such as safari. Third party applications use the normal "login" Keychain.

Once I understood this, The solution was simple enough:

• Open Keychain Access
• Select the "login" Keychain
• Secondary click the "login" item in the list and select "Lock Keychain 'login' "
• Alternatively click the (unlocked) padlock above the list.Secondary click the 
• "login" item in the list and select "Lock Keychain 'login' "
• Secondary click the "login" item in the list again, and select "Unlock Keychain 'login'"
• Alternatively click the (locked) padlock above the list.
• You will be prompted to enter the Password of the Keychain, this password usually is the same as the password of the account you used to login.

Cheap simple common port forwarding in javase 6, and noninvasive proxying

Today I spent most of my day trying to get a third party java WS-client running in an application server to access an external server outside the corporate firewall at work.
After some feeble attempts (and, ofcourse failures) I had a chat with the network/fw guys they offered severall ways to do it. Using a http-proxy, a socks-proxy or some kind of port forwarding.
As the client is running in an application server, I was not so keen on setting -Dhttp.proxyHost or -Dsocks.proxyHost and their friends.

Doing that might unintentionally muck up someone else's outgoing connections.
The execution environments of application servers do tend to behave in mysterious ways, when you change things at a global level, as you might be sharing the jvm with another application, if possible, don't muck up Their proxy settings. I find that designing applications as noninvasibly as possible always helps, at least.

However, reading Java Networking and Proxies, it mentioned the sweet little interface java.net.ProxySelector that was just what got the job done beautifully.

I simply bootstrapped my MyProxySelector extends ProxySelector at startup of the application server, and replaced the default ProxySelector and stored the previous default to use for all calls that did not apply to "my" URIs on the Internet. When the ProxySelector.select(URI) method got invoked with the host:port etc that I wanted to proxy, a new Proxy("my.socks.ip.addr",port) was returned alright, and the socks proxy ofcourse denied me access (I still have some paperwork to do to the fw guys to open up the proxy/fw)

So what about port forwarding? As I did not have contol over how the Axis client got it's URI, this was "hidden" in the third party code (I find jadclipse very useful), I could not use the trick I hoped for...

Here is the outline of what I would have done, if I would have had more control of how the InetAddress was created:
To do a very simple port forwarding client, set up the portforwarding device, lets say gw.mysite.org:1234 to forward all calls to it to internetsite.oninternet.com:1234
To make your https://, socket:// or http:// client connect via the gw.mysite.com, just use the InetAddress.getByAddress(String host,byte[] addr) method, passing "internetsite.oninternet.com" as first arg and the ip of gw.mysite.org as second arg. It does not attempt to resolve the address or anything. Havent tried it, might work. No liabilities.