WPF Command.Text

I'm not sure why it never occurred to me before, but this might help clean up some of the code out there where buttons are bound to commands.

The standard way I have been binding to buttons is to set the command and then set the content like one of the following:

<Button x:Name="PlayButton" 
        Command="{Binding PlayCommand}">Play</Button>
<Button x:Name="Help"
        Command="ApplicationCommands.Help" 
        Content="{Binding RelativeSource={RelativeSource Self}, 
                 Path=Command.Text}" />

Which in the first case just repeats the word "Play" three times and in the second case is just plain ugly and not something you would want to reproduce everywhere just to infer the content from the Command when typing "Help" would be easier to type and to read. Yeah obvious, now that I spell it out to myself. I should just set my default style on my buttons to be something like this and include it in my skins/app.xaml

<Style TargetType="Button">
  <!--Default Button content to be the Text provided from the Command.-->
  <Setter Property="Content" 
          Value="{Binding RelativeSource={RelativeSource Self}, 
           Path=Command.Text}"/>
</Style>

Now all buttons will try to set their content to the Command's Text property if it has one (RoutedUICommands do). If the command doesn't expose a Text Property or the button is not bound to a command, well I still was going to have to code some content anyway so no big loss.

What's in a name?

A rose by any other name....

Well not in software Romeo. Colin at Abstract.com posted an entry on obvious comments and how they probably indicate rubbish design/naming of methods and variables.

I am just stumbling into this kind of thing now. The client has asked for "Attachments" to be added to an entity in a system I am working on. When they say attachments they just want to upload documents and them to be linked to the entity. Sounds reasonable. So a developer has gone off and created an Attachment class.

I might be being picky here, but to me there is a subtle difference between Attachment, File and say Document or Image. Attachment describes a relationship, File describes an entity representing a file. You may sub class File with Document which might expose a Title, Subject Author properties. You may sub class File with Image and provide Width & Height Properties. But I doubt you would ever have a type of Attachment. If I wanted to add attachments to an entity I could call its void AddAttachment(File attachment) method with my uploaded document, image or simple file. To retrieve them I might use

IEnumerable<File> ListAttachments()

method or maybe just a simple

IEnumerable<File> Attachements

property.

Yeah its picky. Instead of just poking fun at someones design I may try to resurect an old design I had for this space (cheap and nasty DMS), and post it for public mockery.

Google SketchUp

Following on from the Balsamiq post, I stumbled upon Google SketchUp. I dont think it will be much use for designing software (well at least not 2d software) but looks fun. At version 7 I figure as usual I am well behind the pulse of the market.

Web security

I recently helped a friend evaluate a web she had developed for her. The business is essentially a web based business, but she is not a web developer herself so had the development outsourced to a reputable local web design company. At first she was happy with the result them some things were going a miss and one of her business partners who fancied themselves as a hobbyist nerd found a security hole. This raised some concerns and then she approached them and they had it fixed up. When Alice* told me about this I was rather uncomfortable with the whole scenario. How is a hobbyist able to identify security holes in a web site?!

Alice sensed my concern (probably due to the swearing and head in hands), and asked if I was able to have a quick review of the site. The good news was they fixed up the SQL Injection vulnerability. Bad news was, that was about it. Now I am a professional developer working exclusively in the .NET space. I am aware of certain security issues and would place myself as a somewhat knowledgeable in areas of security, but by no means a Bruce Schneier or Keith Brown. It took me 4 hours with the use of notepad, skydrive and a browser (ie free and available software) to have cross-site scripting attacks up and running. I was able to fetch my own password from the cross site script and also hijack my session. Having done this I flicked Alice an email and let her know the bad news.

This made me think, are the web developers out there writing secure applications yet? In fact is anyone? The last place I worked, they commissioned a guy to write his own custom federated security model for an internal system. Yeah the words Federated and Internal seem to conflict eh. Well that system took only 90mins to hack open. Irony is that Windows Authentication would have been more secure and faster. The place I am currently working they have a recommendation to store username and password pairs in *.config files when trying to authenticate across multiple servers (Kerberos hop anyone?). This obviously is worrying.

So I thought I would throw together a refresher list of things you need to do to make your system, well not insecure.

1. Don't store passwords. That's right you don't need them. Ideally you should be using an authentication system (OpenAuth, AD/LDAP etc.) but if you need to roll your own you only need a salted hash of the password to perform a comparison for authentication. Storing passwords is just asking for trouble. If you consider all of the systems the users have to log in to there is a very high chance that either their password is the same everywhere or they have a pattern for picking passwords. If I can hack your Database of passwords then not only can I hack you site, but there is a good chance that I can now hack these user's accounts in gmail, facebook, linkedin etc and even worse...bank accounts or work accounts.
2. Sanitise your inputs, and even better don't ever "evaluate" user input as code this comic is a great parody of this. An easy target of this is SQL Injection attacks. SQL Injection attacks just make me shudder.
3. As above, only use parameterised SQL. This doesn't favour SPs or dynamic SQL. I have seen vulnerable code in both, but neither needs to be vulnerable.
4. In web development, never display foreign or user input to the screen with out encoding it. This is how session hijacking occurs. (basically repeating myself on evaluating user input)
5. Use HTTPS for login screens or any screen that passes private/protected data.
6. .Net developers should strong name critical assemblies. If you don't, some one can basically use reflector to recreate your assembly and replace your implementation with theirs. I have used this to replace the assembly that performed the login. My implementation was identical except that I logged passwords to a location that I could read later. Interestingly the compiled assembly was identical in size even though I had added code. Changing the file created/modified date to the original wasn't a hassle so no one would be any wiser.

Rocky H used to have a brilliant video on "Assembly Hijacking" which showcased a combination styles of attacks to basically take over a server. The link I have (and the ones Google finds) are dead links. I have emailed him to see if we can get it back on line. Required viewing.

I hope the information here helps someone. If you dont know what any of the jargon above means in detail then there is a great chance that you are writing insecure code. Just Google/Wiki the phrase you don't know, it will take you 10minutes to learn what it is and how to prevent it. Otherwise feel free to ask.

*Alice is not her real name

balsamiq - UI Mock tool

Check out this neat little UI Mocking tool. http://www.balsamiq.com/ Really simple and fits with my preference for "Crayon drawing" UI mocks. My problem with life like mocks (contradiction?!) is that you end up being bound to the UI instead of the functionality that the client wants.