it seems that aol has decided to start giving out your aim name — based solely on an email address.
i’m not sure when this started happening, but i will describe how to see and confirm the behavior.
this is a very bad move on aol’s part. when an aim account is created, the user is supposed to provide a valid email address. this email is used to confirm the account (an optional step) as well as facilitate forgotten passwords, etc. that email was provided to aol with the understanding that it would not be shared. this new behavior is a breach of that trust.
it’s time to announce my second plugin for ruby on rails, limited_sessions.
it’s been publicly available for several days, so i guess it’s time that i actually talk about it.
this came out of a need to manage sessions more intelligently than rails does by default. all of these is built as an extension to ActiveRecordStore, so sessions must be stored in the db. features:
configurable, server-enforced session expiry time (eg: 2 hours from last access)
optional hard limit on session from login time, regardless of access (eg: 8 hours from login)
ability to tie session to user’s IP or /24 subnet
auto-cleaning of expired sessions from db without an external script or other helper
the restful scaffolding generator for rails uses various http status codes when sending results back to the client.
i was adding some additional methods and wanted to use status codes myself, so i went looking for a list of them. i didn’t readily find it in the docs and ended up looking through the source to action controller.
in ruby’s CGI::Session module, sessions are stored as a block of seeming junk, like this: “BMZWRlcm1hbiBCb25kaW5nIENvb”. it’s actually an encoded format which is all well and fine until you need to read something out of it for debugging purposes.
if you are using rails’ ActiveRecordStore, the contents of a session can be read fairly simply. since this relies on an AR model called Session, which your app most likely doesn’t have, we’ll create that too.
so, fire up 1script/console and input the following:
a brief hint about setting up apache 2.2’s mod_proxy_balancer with a mongrel cluster.
if you receive a permission error, “client denied by server configuration” when accessing your apache install, check the proxy configuration. in this case that means the proxy balancer configuration. an example working config:
1<Proxybalancer://mongrel_cluster>2 BalancerMember http://127.0.0.1:8000
3 BalancerMember http://127.0.0.1:8001
4 Order deny,allow
5 Deny from all
6 Allow from all
7</Proxy>
the key is the last 3 lines, Order…, Deny…, and Allow….
this usually comes from a more general proxy permissions config:
1<Proxy*>2 Order deny,allow
3 Deny from all
4</Proxy>
this protects against other kinds of proxy support in apache being publicly accessible, and is a good thing. so leave that in place, and just specifically allow access to the balancer proxy.