mysiteonline™

I needed a way to authenticate users from our library from a server outside our network, and therefore also not connected to Active Directory. At first I was thinking LDAP would be the best way...then I did my research and learned enough about LDAP to realize just how much information it gives out - WAY too much for it to be very secure. Even if I used SSL, created an account specifically for this access, set that account to read only...all it would take would be one person to hack our server and grab that information and all our organization's data is out there. Although it's about as much of a chance as getting hit by lightning in the middle of the desert in a sand storm, I wouldn't want to be responsible.

The only server with any sort of external web presence that is also touching the internet is our Exchange server's web access portal. I thought, "Ah HA! I can use cURL, or streams, or fsockopen or something to fake a login to this page to verify authentication!" After searching a bit (I'm terrible every time I attempt to write something using cURL to authenticate), I came across a few things.

1. Exchange Server 2007 uses SOAP to provide a web service...AWESOME! We currently use 2003 though, but we will be upgrading later this year, so this may be helpful later on. [Link]
   1. HowToForge article on how to use PHP with 2007's SOAP Web Service
2. I found this PHP script that I tested, which successfully contacted our OWA server and authenticated.
3. I also found a PHP class on Google Code from Tyler Hall - it's not any particular project repository, just miscellaneous code he's hosting. It looks like it's slightly more feature rich, allowing info from address books and a user's inbox, for example.

I only needed to authenticate our building, so thankfully we had our own subdomain (not sure of the proper terminology) in the AD... If your domain was example.com (DC=example,DC=com), just getting OUR office (assume "Office1") was as easy as defining office1.example.com (DC=office1,DC=example,DC=com) after the @ symbol in the user's username (typically unnecessary information with OWA, but adding it explicitly was important here). It (seemingly) worked perfectly.

If you plan on doing something similar, just make sure that you cache (and encrypt) username/password information locally, hitting the OWA page continuously would probably make your System (or Email) Administrators a little unhappy with you.

Occasionally I'm working on something that has to scrape data, either from an HTML file, XML, or something similar. I'll often think of XPath for its sheer simplicity over REGEX. Thankfully, while looking for a solution on how to "screen scrape" Outlook Web Access to verify login credentials (mimic internal authentication to AD externally), I accidentally came across a blog post discussing this Firefox plugin by Brian Slesinsky. It allows you to simply right click on a DOM node in a page (or source file) and visually test your XPath queries to see the matches it will give back.

Firefox Plugin: XPath Checker

It seems that the days of the librarian (as the field stands now) may be numbered. A new product dubbed "Wolfram Alpha", will be released in May (the Alpha) that intends to actually formulate answers to questions posed to it. They claim it's much more powerful than Google as it actually answers the questions, not finding possible pages that may have answers in it.

Source: http://www.twine.com/item/122mz8lst-4b/wolfram-alpha-is-coming-and-it-could-be-as-important-as-google

So it's been quite awhile since I've discussed anything about my little Adobe AIR project - with good reason, I'm a top-down programmer. If I don't know the language, I need to know enough to come up with a good plan of attack so that I'm not coding garbage that would have to be completely reprogrammed from scratch 2 months later (6 months? ...well...). In that end, I've been trying to find good documentation. The Adobe site had the v1.1 runtime documentation, but I couldn't find the newer v1.5 runtime docs. The library system had a book or two, so I took one out. It wasn't that great. Our library got one specifically for v1.5. It was better, but still not quite what I was looking for (though it made some more basic things easier to understand).

Eventually I found the v1.5 runtime documentation on Adobe's website. It was 433 pages long, in a compiled PDF. Yay. I fall asleep after reading two paragraphs. "This won't be easy," I thought to myself. Well, approximately 200 interruptions later, I finally finished the documentation and I've finished a basic mockup for the user interface. I intend for it to be (upon application instantiation) automatically positioned at the user's bottom right viewport. We'll probably set it in the Program's menu Startup folder.

Example mockup image:

Note: The hover property of the button is not set in this mockup (I rushed a little), and Safari's rounded corners (Adobe AIR uses a version of WebKit for it's HTML rendering engine) are much cleaner than Photoshop's.