Version Control and Sensitive Data

Don’t put passwords in your repositories.

 

 https://help.github.com/articles/remove-…

Web Accessibility Under the Law for Harvard

What is required? Harvard is required to adhere to Section 508 of the Rehabilitation Act of 1973 (The most important Section of which is 504, but that doesn’t directly apply to web development).

The best way to understand the requirements of Section 508 is to read through the text of it. Specifically 1194.22 and by proxy, 1194.21. It should only take a few minutes. It’s not as bad to read through as the W3C’s Web Content Accessibility Guidelines (WCAG). And, more importantly it’s not as comprehensive.

Once you get the highlights, WebAIM has provided a handy checklist. WebAIM is an open consortium that exists just for discussions such as this, similar to what OWASP is for Security. From the spec, (a) through (j) are reasonably straightforward. (k) needs to be understood, as “text only versions” seems to be a common accessibility misconception and isn’t necessary if all of the other items are taken care of.

(l) is a biggie because it requires a different approach to javascript than 99% of js writers do. What it means is to make all interfaces possible to navigate without a mouse, in a way that’s readable to screen readers. That just means following the spirit of (a) through (j) as it pertains to your interface. This seems borderline impossible when you look at things you’ve built and try to add it in after the fact, but is much more reasonable when you design it from the start with this in mind.

Which seems to be a recurring theme when it comes to best practices. These things need to be thought about from the start, not thrown in last minute. So I think the solution for this is to spread information around. Not try to force this into existing projects, but bring them up as new projects / rewrites begin. It’s a lot to think about, I think the trick is to introduce the topics slowly but consistently into our culture until it becomes something we all know and just do without having to be told.

Is Harvard Required by Law to Comply to Accessibility Standards?

Simple answer: Yes.

I have been looking all over for an answer to this. Is there actually a law that defines what we (Harvard University) need to follow in terms of web accessibility? If you search for accessibility law (in the US), you’re basically only going to find references to Section 504 and Section 508.

These are “sections” of the Rehabilitation Act of 1973. So all sections (amendments) are equally applicable.

From the Office of Civil Rights (OCR) Brochure:

The Office for Civil Rights in the U.S. Department of Education enforces regulations implementing Section 504 with respect to programs and activities that receive funding from the Department. The Section 504 regulation applies to all recipients of this funding, including colleges, universities, and postsecondary vocational education and adult education programs. Failure by these higher education schools to provide auxiliary aids to students with disabilities that results in a denial of a program benefit is discriminatory and prohibited by Section 504.

This brochure is linked from the Accessible Education Office’s page on student’s rights.

What this means as far as what is required is a bigger question, and not one I want to write up right now.

Documenting Documentation

I recently waded back into simple web application development (more on how that feels later), and one of the many aspects of coding that I’ve been refreshing myself on is how to best document what I’ve written so my future self doesn’t get too confused over what I implemented or why I implemented it in the way I did. The application is deadly simple, so simple that I hesitate to call it an application. The web page contacts a PHP script via an Ajax call, and the PHP script does its thing, sending back a JSON-encoded object. The client subsequently uses the object to display a message of success or failure.

As I said, deadly simple.

Nevertheless, as simple as the application is, I’ve been researching how best to document PHP and JavaScript. For PHP, the definitive answer appears to be phpDocumentor 2. For JavaScript, there is JSDoc. Here are some additional links that I found useful:

phpDocumentor

JSDOC

Note that I haven’t actually tried generating documentation with either toolset; that’s a completely different challenge. I’ve mostly been following the format so that my documentation can be printed/generated if somebody (aka me!) wishes. And what I’ve come to understand is that learning how to document a language feels almost as complicated as learning the language itself.

 

Javascript Callback Scope

I ran into an annoying issue with js callback scope recently and wanted to document it for myself somewhere. Callbacks are super simple at the core — passing a function as a parameter to another function.

callbackFn =  function(){
  alert("bam");
}
firstFn = function(callback){
  callback();
}
firstFn(callbackFn);

That’s all well and good so long as everything is in the global scope. But that’s just bad practice.

So in OO js, you’d have something like this:

Obj = {
  callbackFn: function(){
    alert("bam");
  },
  firstFn: function(callback){
    callback();
  },
  secondFn: function(){
    this.firstFn(this.callbackFn);
  }
}
Obj.secondFn();

This will actually be executing callbackFn in the global scope. The ‘this’ just gets lost. Note that you may only notice this if you’re expecting the this of callbackFn to find what’s in your obj (the above sample will probably work just fine).

Obj = {
  myalert: function(){
    alert("bam!");
  },
  callbackFn: function(){
    this.myalert();
  },
  firstFn: function(callback){
    callback();
  },
  secondFn: function(){
    this.firstFn(this.callbackFn);
  }
}
Obj.secondFn();

There, that one will fail.

The solution is to use the apply() function.
 https://developer.mozilla.org/en-US/docs…

Obj = {
  myalert: function(){
    alert("bam!");
  },
  callbackFn: function(){
    this.myalert();
  },
  firstFn: function(callback, callbackObj){
    callback.apply(callbackObj);
  },
  secondFn: function(){
    this.firstFn(this.callbackFn, this);
  }
}
Obj.secondFn();

And that will work as intended.

Why PHP Tidy didn’t work for me

I have to fit most of my applications within the confines of an LMS that requires everything it gets from my application to be valid XHTML. This causes an issue when displaying code users input or (in this case) 3rd party libraries are whole hog html5.

I don’t want to say you should close your tags, even in html, but you should.

So I’m using wysihtml5 for my wysiwyg needs. I wanted something smaller and cleaner than TinyMCE. What I got was something smaller. The issue created by wysihtml5 was they were doing img tags with document.createElement(‘IMG’) — which by default creates an unclosed void element. Now if you append that void element to an xhtml doctype, the browser will automatically fix it, but if you’re taking the toString of it and throwing it directly into a database, it will stay

So I decided to try and filter the entire app before it got sent to my LMS with PHP Tidy. tidy_repair_string will take a string, some config options and “fix” most validation errors.

echo tidy_repair_string($content,
array(
'output-xhtml'=>true,
'doctype'=>'omit',
'show-body-only'=>true
));

This worked almost perfectly. The only issue was wysihtml5 uses textareas. And the imgs go into the textareas. And that’s a violation of xhtml. So what does Tidy do with that violation? It just strips out the img (it also strips out brs). And there is no config option to stop that from happening. “Don’t correct this validation violation.”

So what am I stuck with?

preg_replace("/(]*)>/", "$1/>", $content);

Lame.

 http://stackoverflow.com/questions/10028…
 http://stackoverflow.com/questions/75395…
 http://stackoverflow.com/questions/70030…

 http://www.php.net/manual/en/tidy.repair…
 http://tidy.sourceforge.net/docs/quickre…

 http://stackoverflow.com/questions/15365…

OWASP Top 10

Often software developers like to ignore security concerns because it’s a huge time sink. Regardless, it’s a great idea to review the OWASP top 10 every so often to make sure you’re refreshed on what to look out for.

1) Injection
taking parameters directly from the query string into a query
use parameterized queries

2) Broken Authentication and Session Management
sending the sessionID in the query string
store sid in cookie only

3) Cross Site Scripting (XSS)
taking parameters directly from the query string and printing them on the page
all user supplied input sent back to browser needs to be properly escaped

4) Insecure Direct Object References
no checking when query parameters are requesting actions that shouldn’t be allowed by the current user
use indirect object references (don’t use db keys in the view, but rather have an internal mapping to the db keys that would obfuscate them)
Or check authorization on every action

5) Security Misconfiguration
general security issues. default passwords, outputting errors, software (dbms, apps, libs) patches
change default passwords
turn off error outputting / all debugging
be proactive about applying software patches to components

6) Sensitive Data Exposure
encryption (storage and transit)
encrypt “sensitive” data
public key encryption with private key decryption only on the backend

7) Missing Function Leven Access Control
UI showing access to admin functions, functions not checking authentication appropriately, checking authentication on server done without relying on user provided information

8) Cross-Site Request Forgery
– each link and form should include an “unpredictable token” otherwise, you can’t be sure it’s a forged request

9) Using Components with Known Vulnerabilities
– keep up to date on the libs you use

10) Unvalidated Redirects and Forwards
– don’t put part of (or the entire) redirect url in the query string

Workspaces

Yesterday the New York Times posted an interesting article about research in the field of inactivity studies and the trend of workplaces transitioning to upright workspaces (standing desks), particularly at top tech companies. There has been a steady stream of articles and blog entries about the topic over the last few years. Is it just a fad? What are the implications for productivity and learning (if any)?

Posted in Uncategorized. 1 Comment »

Agile Documentation and Research Stories

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Checking your syntax on commit

A good IDE can spot programming syntax errors and alert you to them before they ever make it into a git commit. However, sometimes when you’re in a hurry, tired, or distracted, these alerts go unnoticed and there is a greater risk that you’ll commit broken files to your git branch. Git makes it a snap to revert changes, but wouldn’t it be nicer if you could prevent it from happening in the first place?

To that end, git has a nice feature called client-side hooks. In particular, you can create a hook known as a pre-commit hook that executes right before you commit something. It gives you the option to abort if something doesn’t look right. Using this feature, I created a simple script to check PHP and Javascript syntax on commit. It’s helpful for those mornings when I haven’t quite had enough coffee yet.