Sent out a mailing regarding next year's workshops.
Total sent out was 2375. 2348 to web site list, 21 to workshop schedule update one-time notification, 3 more to 2061 staff not on the other lists.
The bounces weren't nearly as bad this time as last (thanks to my constant efforts to keep the list clean). There were quite a few "Out of Office" and "Mailbox Full" bounces, but that's to be expected this time of year. So far only two have been bounced because of SPAM filters, which is much better than last time. Of course, it'll take a few days to get all the bounces, but so far a good start.
Wednesday, December 29, 2004
HS Bio Textbook Report
Complete. Pretty Much. I mean, no doubt a few edits will need to be made. And there are a few PDFs that need to be added. But otherwise we're pretty much done.
Some of the templates ended up being a little more complex than I had initially planned (extra editable regions, options regions, etc) but overall I think it's worked out fairly well. Of course, the templates aren't flexible enough to use for the remainder of the reports (to be released who knows when) unless I add optional regions, etc ... but I think I'll just go with new templates. They won't be drastically different from the current ones so the additions should be pretty easy to work up.
I have some reservations about our "help text." There's no definitive indication of what happens when the help icon is clicked beyond the text just appearing. It's possible that a less alert user could miss this. Also, though it's not too intrusive, the quesion/circle icon does interrupt the document flow somewhat (though I have seen similar schemes used on other sites).
I was thinking of trying another method such as linking the text itself but modifying the link to be the same color as the normal text with maybe a light underline and have the cursor change on mouseover. There are two problems with this method, however. 1) It would interfere in cases where normal links were needed. 2) It might be a little too "under the radar" for the average user to notice.
I had another thought about a floating "mini-reference" that could be used to provide the additional information. Unfortunately it would require a significant amount of time to program. Time that I'm not willing to put in at this late in the game (unless specifically requested to do so).
I added a new function to the reports, a "toolbar" that's added to the top of a page with a link to print the document. The script is fairly intelligent and requires no coding to use. All that's needed is for the script to be included on the page. The main drawback is that the script only works on modern browsers. Here's a quick run-down:
Some of the templates ended up being a little more complex than I had initially planned (extra editable regions, options regions, etc) but overall I think it's worked out fairly well. Of course, the templates aren't flexible enough to use for the remainder of the reports (to be released who knows when) unless I add optional regions, etc ... but I think I'll just go with new templates. They won't be drastically different from the current ones so the additions should be pretty easy to work up.
I have some reservations about our "help text." There's no definitive indication of what happens when the help icon is clicked beyond the text just appearing. It's possible that a less alert user could miss this. Also, though it's not too intrusive, the quesion/circle icon does interrupt the document flow somewhat (though I have seen similar schemes used on other sites).
I was thinking of trying another method such as linking the text itself but modifying the link to be the same color as the normal text with maybe a light underline and have the cursor change on mouseover. There are two problems with this method, however. 1) It would interfere in cases where normal links were needed. 2) It might be a little too "under the radar" for the average user to notice.
I had another thought about a floating "mini-reference" that could be used to provide the additional information. Unfortunately it would require a significant amount of time to program. Time that I'm not willing to put in at this late in the game (unless specifically requested to do so).
I added a new function to the reports, a "toolbar" that's added to the top of a page with a link to print the document. The script is fairly intelligent and requires no coding to use. All that's needed is for the script to be included on the page. The main drawback is that the script only works on modern browsers. Here's a quick run-down:
- Using the addEventListener method an onLoad function is added to the document that adds the toolbar
- Not all browsers support the window.print function, so a test is done for it's availability before any other steps
- The function uses DOM scripting to add the toolbar, so a second test is done for the getElementById function
- The toolbar is added using addNode function to create a div that is absolutely positioned at the top of the page using styling
Monday, December 27, 2004
HS Bio Textbook Report
Finished some final edits requested by CT. I just need to finish the indicator show/hide for the instructional analysis reports, which should be easily completed tomorrow.
There might be a few last-minute edits/fixes, but we're pretty much ready for to publish the reports.
There might be a few last-minute edits/fixes, but we're pretty much ready for to publish the reports.
Checking the locks
Nothing spectacular today. One exploit scan that was from a smaller range. I reported the scan, but don't expect much of a result since the offending owner is in China.
Wednesday, December 22, 2004
HS Bio Textbook Report
Staff want the indicators to be available on the instructional analysis page via show/hide functionality. I've taken functionlity that I had written previously and modified it to be a little more generic. I'm still not sure if the method I've chosen to provide the functionality requested is the best one, but I think it'll do for now. I still have to document the code, which I guess I'll get to tomorrow.
I'm running into two problem I'm not sure how I'm going to address just yet.
One, the styling for the text around the show/hide area diverts from the requested styling. I know why it's doing this (margin stylings and those cursed rules for collapsing margins), but I'm not sure how I'm going to address it just yet. It's a fairly inocuous problem ... a little extra space below the item, but it's one that seems to be a sticking point for the comm staff. There are a number of ways to work around this problem, I just need to find the one that requires the least amount of fudging.
Two, Mozilla doesn't want to play nice with the script. It's not stopping propagation and thus following the back-up link specified for compatibilty with non-js browsers. I'm sure I'll figure out what's going on eventually.
Update 2004-12-23: Fixed the problems I referenced above.
One - since the styling was being affected by adjacent margins I ensured that the margins were not "touching" by adding a 1px padding to the bottom of the container div. IE had no problems to begin with since it does not implement collapsing margins correctly. Problem solved.
Two - the DOM event model doesn't allow for a return value from an event added using the addEventListener method. IE had no problems because 1) it ignores this rule and 2) you can always use the event's returnValue property to provide a return value. The DOM does, however, include a method to prevent the default action from occuring, preventDefault. Problem solved.
Update 2004-12-23: No sooner did I think I'm done than another problem is encountered. Looks like Safari doesn't support the preventDefault method. I'll have to do some research next week.
Update 2004-12-27: After a bit more research I found plenty of references indicating that Safari does in fact support preventDefault. Safari itself indicates that it supports the method, but I have been unable to get it to not follow a link by using the method. I'll probably do a little bit more research tomorrow, but for now I've coded up a work-around that is acceptable (if not desirable). When Safari is detected the link is modified to be "javascript: return false". It may be ugly, but it works.
I'm running into two problem I'm not sure how I'm going to address just yet.
One, the styling for the text around the show/hide area diverts from the requested styling. I know why it's doing this (margin stylings and those cursed rules for collapsing margins), but I'm not sure how I'm going to address it just yet. It's a fairly inocuous problem ... a little extra space below the item, but it's one that seems to be a sticking point for the comm staff. There are a number of ways to work around this problem, I just need to find the one that requires the least amount of fudging.
Two, Mozilla doesn't want to play nice with the script. It's not stopping propagation and thus following the back-up link specified for compatibilty with non-js browsers. I'm sure I'll figure out what's going on eventually.
Update 2004-12-23: Fixed the problems I referenced above.
One - since the styling was being affected by adjacent margins I ensured that the margins were not "touching" by adding a 1px padding to the bottom of the container div. IE had no problems to begin with since it does not implement collapsing margins correctly. Problem solved.
Two - the DOM event model doesn't allow for a return value from an event added using the addEventListener method. IE had no problems because 1) it ignores this rule and 2) you can always use the event's returnValue property to provide a return value. The DOM does, however, include a method to prevent the default action from occuring, preventDefault. Problem solved.
Update 2004-12-23: No sooner did I think I'm done than another problem is encountered. Looks like Safari doesn't support the preventDefault method. I'll have to do some research next week.
Update 2004-12-27: After a bit more research I found plenty of references indicating that Safari does in fact support preventDefault. Safari itself indicates that it supports the method, but I have been unable to get it to not follow a link by using the method. I'll probably do a little bit more research tomorrow, but for now I've coded up a work-around that is acceptable (if not desirable). When Safari is detected the link is modified to be "javascript: return false". It may be ugly, but it works.
Site Design
There's a lot of work to do to prepare for the upcoming site re-organization, not to mention all the work required to complete the site re-org. I spent a little bit of today modifying the site style so that two-line sub-items on the left hand navigation menu are possible. The previous style was ok for single-line entries in the navigation, but we have a few that are likely to wrap.
The previous style caused problems because the same amount of space was between soft returns (wrapped lines) as was between hard returns (br tags). Everything kind of ran together. I modified the style so that the links in the menu are treated as block items, have a smaller line-height than before, and a little space above and below to set each individual link off from it's neighbor. I also used display:none for the br tags so no extra space was present (I kept those in for browsers that don't handle display:block ... thus hiding them using styles otherwise).
The previous style caused problems because the same amount of space was between soft returns (wrapped lines) as was between hard returns (br tags). Everything kind of ran together. I modified the style so that the links in the menu are treated as block items, have a smaller line-height than before, and a little space above and below to set each individual link off from it's neighbor. I also used display:none for the br tags so no extra space was present (I kept those in for browsers that don't handle display:block ... thus hiding them using styles otherwise).
Tuesday, December 21, 2004
SVG Plug-in OS-Browser combos
FM had me test the various OS-browser combos to see where the Adobe SVG plug-in works. Of course, we don't have a fully featured test lab so I had to make some estimations based on what I observed and what the documentation for the plug-in states.
Overall I'm not sure how accurate the testing was. I think it better to know what platforms are being targetted/supported and test for those. Still, there's only a limited amount of testing we can do and many variables that can affect the functionality of a plug-in (OS version and what updates are applied, browser major/minor version, etc).
Overall I'm not sure how accurate the testing was. I think it better to know what platforms are being targetted/supported and test for those. Still, there's only a limited amount of testing we can do and many variables that can affect the functionality of a plug-in (OS version and what updates are applied, browser major/minor version, etc).
HS Bio Textbook Report
Just about done with the styling of the reports. Today I modified the CSS to use @media declarations so I could include both a print and screen style for each document. Shared styles are currently located in an @media print, screen ... but this causes Nav 4.x to ignore the styling. Not a horrible result by any means, and Nav 4.x is a fairly small percentage of our regular traffic these days. Plus it gives me a good idea of what the reports look like without any styling at all.
I still need to check on the Mac to make sure no major problems are encountered.
One last element to add to the instructional analysis template, the indicator text. I have some ideas I want to toy around with. I also thought of a decent compromise on inclusion considering the variability of whether the indicators are addressed from one report to another. I'm waiting to hear back on the final decision in the meantime.
Update 2004-12-21: Finished testing on the Mac. Looks good on Firefox, Safari, and Mozilla-based browsers (Navigator 6+). IE works about as well as Nav 4.x. I have no intention of addressing the issue, however, since IE is a dead browser on that platform (unless we get complaints about it).
I still need to check on the Mac to make sure no major problems are encountered.
One last element to add to the instructional analysis template, the indicator text. I have some ideas I want to toy around with. I also thought of a decent compromise on inclusion considering the variability of whether the indicators are addressed from one report to another. I'm waiting to hear back on the final decision in the meantime.
Update 2004-12-21: Finished testing on the Mac. Looks good on Firefox, Safari, and Mozilla-based browsers (Navigator 6+). IE works about as well as Nav 4.x. I have no intention of addressing the issue, however, since IE is a dead browser on that platform (unless we get complaints about it).
Monday, December 20, 2004
Wednesday, December 15, 2004
Site reorganization
I'm in the process of moving files around on the site to better enable automated mapping tools. It's a bear of a process and I think a virtual re-org needs to take place as well. Our content has always been a bit difficult to weed through to find the gems. The physical re-org will help us get a better feel for the documents that are on the site. But in order for our site visitors to be able to find things I think we need to do a better job of grouping and highlighting.
I'll need to spend a few days thinking about this. Maybe I'll be able to better elucidate the thoughts in my head after I've begun working with the documents.
I'll need to spend a few days thinking about this. Maybe I'll be able to better elucidate the thoughts in my head after I've begun working with the documents.
2005 Workshops
New workshop information is ready to go up. Nothing special here, just a few HTML and PDF pages. Still, it's a lot of work to ensure that all the information is correct.
We'll be sending out a note to our e-mail alerts list announcing the new dates soon.
We'll be sending out a note to our e-mail alerts list announcing the new dates soon.
Monday, December 13, 2004
Checking the locks
A few exploit scans on the system, most of it fairly typical. No IP blocks small enough to make it worthwhile to report.
The reporting from last week on the unique worm that was parsing our Web site never received a response. Either the owner of the source IP block was complicit in the activity or doesn't really care. I suspect the latter and that they don't even check the address used for their whois information.
The reporting from last week on the unique worm that was parsing our Web site never received a response. Either the owner of the source IP block was complicit in the activity or doesn't really care. I suspect the latter and that they don't even check the address used for their whois information.
Friday, December 10, 2004
Firefox bug?
While working on the HS BIO reports I've run across what appears to be a bug in Firefox. Actually, it looks to be a bug in the gecko rendering engine as the bug is present in both Firefox and Mozilla 1.8A5.
The gist of the bug is that the rendering of an block element (div, blockquote, etc) that has no padding is done incorrectly when that element contains another block element that has a margin (h1, p, or a block element that has a styled margin). The top/bottom margin of the inner element appears to be rendered as the top/bottom margin of the outer element.
I'm working on some test cases so I can submit the bug to bugzilla. I'll need to search through the current bugs first, though, to ensure I'm not duplicating efforts. Perhaps I'll find the time on Monday to complete my introduction to the open source community.
Update 2004-12-13a: Posted a bug report ... an experience I'm a bit anxious about. I've not done it before so I hope I get a good reception. I also hope I haven't reported a bogus/duplicate bug. That would suck.
Update 2004-12-13b: Nevermind. Got the smack-down big time. I need to do more research next time. :(
Update 2004-12-13c: Upon further review I realize how I misjudged the gecko rendering of my code. It all goes back to margin collapsing. Probably one of the more difficult parts of CSS to get a handle on.
Nothing like being humbled by the masters to make you realize how much you still have to learn. I spend too much time assimilating just enough information to get the job done these days (the curse of the JOAT I guess). Or perhaps I just attempt to assimilate too much information. I should spend a little more time delving into the more arcane aspects of some of the technologies I use. Time to look into classes or certification.
I don't think I'll be submitting a bug report anytime soon. There are plenty of people more capable than I working on that kind of stuff. I'll need to keep reminding myself of the old saying about the dangers of having just a little knowledge.
The gist of the bug is that the rendering of an block element (div, blockquote, etc) that has no padding is done incorrectly when that element contains another block element that has a margin (h1, p, or a block element that has a styled margin). The top/bottom margin of the inner element appears to be rendered as the top/bottom margin of the outer element.
I'm working on some test cases so I can submit the bug to bugzilla. I'll need to search through the current bugs first, though, to ensure I'm not duplicating efforts. Perhaps I'll find the time on Monday to complete my introduction to the open source community.
Update 2004-12-13a: Posted a bug report ... an experience I'm a bit anxious about. I've not done it before so I hope I get a good reception. I also hope I haven't reported a bogus/duplicate bug. That would suck.
Update 2004-12-13b: Nevermind. Got the smack-down big time. I need to do more research next time. :(
Update 2004-12-13c: Upon further review I realize how I misjudged the gecko rendering of my code. It all goes back to margin collapsing. Probably one of the more difficult parts of CSS to get a handle on.
Nothing like being humbled by the masters to make you realize how much you still have to learn. I spend too much time assimilating just enough information to get the job done these days (the curse of the JOAT I guess). Or perhaps I just attempt to assimilate too much information. I should spend a little more time delving into the more arcane aspects of some of the technologies I use. Time to look into classes or certification.
I don't think I'll be submitting a bug report anytime soon. There are plenty of people more capable than I working on that kind of stuff. I'll need to keep reminding myself of the old saying about the dangers of having just a little knowledge.
Thursday, December 09, 2004
HS Bio Textbook Report
I think I'm finally making some headway on the templates. I'm beginning to feel like there will be too much variability, thus decreasing the value of templating some of the elements of each page. Unfortunately there's only so much I can do with the various requests. If I spent some time on it I'm sure I could break things up a little more so that there are fewer templates overall. It's too bad I'm spending too much time on this as it is, otherwise I might give it a shot.
After spending days trying to decide on a navigation structure for the actual reports I finally decided to KISS. A more robust navigation system would be nice, but a bit out of place at the current stage of the reports. If necessary I should be able to go back and rework the navigation, but it's looking to me like the system CT and I are discussing may be good enough for the long haul.
After spending days trying to decide on a navigation structure for the actual reports I finally decided to KISS. A more robust navigation system would be nice, but a bit out of place at the current stage of the reports. If necessary I should be able to go back and rework the navigation, but it's looking to me like the system CT and I are discussing may be good enough for the long haul.
Tuesday, December 07, 2004
Webtrends irregularity
Something in one of the log files was causing Webtrends to crash during logfile import. I couldn't find anything too out of the normal, but I was able to identify the section causing the problem. I probably could have narrowed it down all the way, but I didn't feel anymore time was warranted.
Checking the locks
Had a worm scan from an elementary school in Korea (at least, that's what the whois appeared to indicate). It's always nice to be able to contact a small group like that. The large ISPs are pretty much worthless when it comes to investigating abuse reports.
Update 2004-12-08: I found an attack vector I hadn't seen before. I got lucky, though, because the attack showed up in the usage reports. Since I don't parse the server logs I wouldn't have caught it otherwise. Luckily it appeared to come from a relatively small block of addresses. Maybe I'll see some action on it.
The attack appeared to be automated, otherwise I would have expected a more concerted effort. The attack appears to crawl sites looking for ASP pages that use querystrings. I guess the assumption being that one of these sites will use the querystring as input for a SQL statement intended for a MS SQL Server backend. Not a wholly unlikely scenario. Once it finds one of these ASP pages the script requests the page again with a nasty little addition that creates a VBS file using a MSSQL built-in extended stored procedure. The additional querystring data uses pretty traditional SQL injection code that is URL-encoded. The encoded is only done once, though, and so is not caught by URLScan. A follow-up request attempts to execute the VBS, which downloads an executable (http.exe) from the same machine running the exploit scan to windows\system32. Finally, a third request deletes the VBS file. I didn't see any follow-up requests that attempted to execute the downloaded file. Most likely this is only done if the file is actually downloaded (the download request include the domain of the attacked machine).
The attack didn't work in my case for a number of reasons. One, access to the SQL server is established using an account that is fairly limited (and definitely does not have access to the master database where the built-in stored procedures can be found). Two, I'm as likely to use MS Access as I am SQL server. Three, a number of the scripts utilize the recordset object for data access, which I do not believe susceptible to SQL injection. Four, a number of scripts use an INSERT statement that, while not invulnerable to attack, requires more intelligent attack code that is likely to be found in an automated script.
One thing the attack has shown me is that I need to perform better sanitation of the incoming data. Though I doubt any automated script will ever cause any problems, a concerted effort on the part of a hacker would lead to a number of pages that could be used for SQL injection. This won't cause much of a problem with regard to stored procedure access for the reason mentioned above. However, stored procedure access is not the only means by which SQL injection can cause problems.
I'm tempted to give the script-kiddie the appearance that my personal server has been compromised so I can see what happens. I'm just not sure I really want to spend the time on it. Perhaps it'll be more fun to give the appearance that the FBI has been hacked.
Update 2004-12-08: I found an attack vector I hadn't seen before. I got lucky, though, because the attack showed up in the usage reports. Since I don't parse the server logs I wouldn't have caught it otherwise. Luckily it appeared to come from a relatively small block of addresses. Maybe I'll see some action on it.
The attack appeared to be automated, otherwise I would have expected a more concerted effort. The attack appears to crawl sites looking for ASP pages that use querystrings. I guess the assumption being that one of these sites will use the querystring as input for a SQL statement intended for a MS SQL Server backend. Not a wholly unlikely scenario. Once it finds one of these ASP pages the script requests the page again with a nasty little addition that creates a VBS file using a MSSQL built-in extended stored procedure. The additional querystring data uses pretty traditional SQL injection code that is URL-encoded. The encoded is only done once, though, and so is not caught by URLScan. A follow-up request attempts to execute the VBS, which downloads an executable (http.exe) from the same machine running the exploit scan to windows\system32. Finally, a third request deletes the VBS file. I didn't see any follow-up requests that attempted to execute the downloaded file. Most likely this is only done if the file is actually downloaded (the download request include the domain of the attacked machine).
The attack didn't work in my case for a number of reasons. One, access to the SQL server is established using an account that is fairly limited (and definitely does not have access to the master database where the built-in stored procedures can be found). Two, I'm as likely to use MS Access as I am SQL server. Three, a number of the scripts utilize the recordset object for data access, which I do not believe susceptible to SQL injection. Four, a number of scripts use an INSERT statement that, while not invulnerable to attack, requires more intelligent attack code that is likely to be found in an automated script.
One thing the attack has shown me is that I need to perform better sanitation of the incoming data. Though I doubt any automated script will ever cause any problems, a concerted effort on the part of a hacker would lead to a number of pages that could be used for SQL injection. This won't cause much of a problem with regard to stored procedure access for the reason mentioned above. However, stored procedure access is not the only means by which SQL injection can cause problems.
I'm tempted to give the script-kiddie the appearance that my personal server has been compromised so I can see what happens. I'm just not sure I really want to spend the time on it. Perhaps it'll be more fun to give the appearance that the FBI has been hacked.
Thursday, December 02, 2004
I am not spam
Spent most of the afternoon sending off messages trying to convice people that we do not send spam. Some of the filters were way too strict (filtering on the words "contact us"). Most of them also filtered during the SMTP session, which is annoying because then you can't forward the caught message to the postmaster for review. Actually, that's probably not true. It's probably more likely that those people have not omitted their postmaster from filtering. I'll keep my comments to myself.
Of course, all this means I didn't even get to two of the things I wanted to work on today. Alas ... the trials of a webmaster (in the classic sense of the word).
Of course, all this means I didn't even get to two of the things I wanted to work on today. Alas ... the trials of a webmaster (in the classic sense of the word).
IERI Utility
Modified the movie loading page of the utility. First, on the selection page the expected movie is now displayed. Second, when the user attempts to load a movie it is compared with what is stored in the database. If the two don't match the user is asked to try again. This should prevent people from choosing the wrong movie, but the fix is a kludge. I still hope to be able to do drive detection so that the user does not have to locate the movie each time.
FM wants to discuss the porting of the utility from ASP to PHP at some point. I still think it's a premature conversation, however, as I would like to complete another revision before we attempt the conversion. As much time as I have to spend on the utility these days it'll be a few months at the least before I've finished the next revision.
FM wants to discuss the porting of the utility from ASP to PHP at some point. I still think it's a premature conversation, however, as I would like to complete another revision before we attempt the conversion. As much time as I have to spend on the utility these days it'll be a few months at the least before I've finished the next revision.
Subscribe to:
Posts (Atom)