Recently I was asked by one of our librarians to come up with a way to easily add bookmarks to our Internet workstations. A little background on this situation follows. Our Internet workstations are all Linux based, with a custom version of FireFox. This custom version of FireFox has a lot of things disabled to keep the browser in a stable stat. I have removed the ability to modify the bookmarks on the workstation in any way. The event code for drag and drop, the menu items, you name it, its gone. This has made it impossible for the librarians to manage the bookmarks on the workstations themselves. Any bookmark changes have required me to connect to the machines via SSH and manually update the bookmarks.html file. This method was just not convenient, and did not allow for easy updates by any means.
Earlier this week, thanks to the offloading of some tasks to our new employee, I was able to put some thought into this problem. I needed a solution that was easy to maintain, simple for the librarians to use, and most of all, easy to implement. That last criteria ruled out creating something from scratch, which I really didn’t want to do anyway. Earlier in the week a co-worker had mentioned how he had just setup foxmarks on his machine and how it was going to sync his bookmarks both at home and work. It hit me then, why not take a look at foxmarks. I downloaded and installed it in my browser, and it did exactly as it was designed to. I realized then that it was a purely native chrome based app. This fact about its design made it a perfect candidate for what I needed.
I set to creating a generic account for the library, a simple task thanks to the easy to use interface. Once that was done, I installed foxmarks into the browser on one of the Internet stations. Due to the customizations, this was not as easy as it normally would be. ( I have all installation menus, and handlers disabled. Ooops…) I finally worked out a way to install the extension, and once I did I set it to use the newly created account, and checked the box to save the sync password. Foxmarks performed its initial sync, and I was able to confirm the success by browsing the foxmarks website. I then closed the browser, clicked yes on the dialog to clear all stored personal information and felt confident I had a good start. I re launched the browser, hit sync, and foxmarks asked me for the password for the sync account. What? I was certain I checked to save the password. I checked it again, and restated the browser, again clearing the personal information. Sure enough, foxmarks asked for the sync password again. It then occured to me that clearing the personal information was probably clearing the foxmarks password. That would be a problem for sure. Confident that the password hurdle could be overcome, I set about to modifying the chrome files, and was able to hid the configuration menu items, and remove the keystroke sequence for accessing the configuration menu.
foxmarks-overlay.xul
<menupopup id="menu_ToolsPopup">
<menu id="foxmarks-menuitem" label="Foxmarks" class="menu-iconic"
image="chrome://foxmarks/skin/images/foxmarks_bug.png"
accesskey="&menu.accesskey.foxmarks;"
insertafter="devToolsSeparator" hidden="true">
After the UI modifications were complete I again launched the browser, and checked over the browser to make sure nothing was visible that could allow malicious patrons to manipulate the setup. Everything I could think of was tested and it passed with flying colors. I then added a bookmark via the website, and triggered the sync process. After entering the password, foxmarks synced and the new item appeared. Again, I still had to fix the password problem. I closed the browser again, this time un-checking the options to clear the password store. After re-launching foxmarks synced perfectly, remembering its password. This then confirmed for me that foxmarks was indeed using the firefox password store. It makes perfect sense that it would, but of course in this situation, it’s very inconvenient. I again dove into the code that comprises foxmarks. I found, in the foxmarks-settings.js file two functions that handled the username and password. As I suspected they ultimately called “return” with the value for the username and password. A simple one line change to each of these functions resulted in a hard coded username and password that would stay put after a clearing of the password store. By placing a return() just inside the function declaration we essentially bypass the default actions of the functions.
get username() { return "our_foxmarks_user_account"; return this.getCharPref("username", ""); }, get passwordNoPrompt() { return "our_foxmarks_account_password"; if (!this.rememberPassword && this.sessionPassword) {
After saving the modified file, I started up firefox and hit the sync keystroke, presto, no request for password or user name, and the browser synced. I restarted again, making sure to clear the password cache, and again foxmarks worked perfectly. At this point I deployed the modified version of foxmarks to all of our workstations, and sat back and watched the fun. Within a short period of time, every workstation had correctly synced its bookmarks and all was well.
Finally I sat down with the librarians and explained how to work with foxmarks’ website interface. By the end of the first evening after foxmarks was installed we had a healthy collection of frequently used websites all bookmarked, and categorized. The sync process has been working well and we have had no real problems. (there was one point where I had accidentally left one of the browsers restored to its default state and some things were modified, but I caught it quickly and fixed the problem.
This alone would have been a fantastic solution, but not being one to rest on my laurels, today I used foxmarks ability to create RSS feeds from links in folders, and used that data to allow the library to randomly select a link and twitter it. Yup, more fun with twitter.