A few weeks ago, I started thinking about designing custom controls for Silverlight, controls I could re-use in various projects.  Instead of just playing around, I figured I might as well make something I could put to use.  Seeing I didn’t find a true, free drag ‘n drop control, I decided to make one myself.

That little project evolved into a drag and drop manager for Silverlight.  There’s still room for improvement, but I’m quite happy with where the project is at at the moment.  And because other people might be able to use a control like this, I decided to make a Codeplex project, so everyone can get this control for free, including sourcecode! :-) 

For those of you who don’t want to read the rest, here’s the link to Drag and Drop Manager @ Codeplex.  And of course, an online sample!

The Silverlight Drag And Drop Manager consists of 2 controls (and their corresponding event argument classes): *DragSource* & *DropTarget*.  The first one makes any control draggable: just add the control (and if you wish, a ghost for that control) as the Content-property of the DragSource. 

The DropTarget defines a place in your application where you can drop your DragSources.  Every DragSource has a list of DropTargets on which it can be dropped, thus defining the possible DropTargets for a DragSource.  On the other hand, every DropTarget has a Content-property, which can contain anything that's a DragSource (assuming the correct rights).

Typically, you'd create a list of DropTargets & a list of DragSources on screen if you want to be able to drag those DragSources into your DropTargets.  If you want to have two lists, and want to be able to drag the DragSources back to their original position, you 'd create a list of empty DropTargets, and a list of DropTargets with DragSources as their Content.

Both controls can be added to your Silverlight-app using CodeBehind or using XAML notation.  They both expose different events you can bind handlers to, if needed, eg: DragSourceDropped-event, DropTargetEntered event, et cetera.

Next to that, both controls are *highly configurable*, so lots of possible scenarios are available.  Have a look at the sample application to see a few of them in action! 

 

Full sourcecode, documentation, online sample & binary: Drag and Drop Manager.

Comments are welcome, discussions, feature requests, bug reports, …  can be reported @ Codeplex.

Enjoy! :-)

When talking about security for service calls, there are actually a few things to consider.  First of all, how do you make sure the data sent over the wire is encrypted?  That's your first level of security: always make sure the data that's being sent over the wire is encrypted.  After all, unless we're working in an intranet environment, anyone could potentially look at the packets that are being sent. 

Luckily, securing this is easy to do: use SSL/https.  As far as SL/WCF is concerned, this comes down to setting your security mode to "Transport" in your binding.  That's really all there is to it.

On to the next level, what this is all about: securing your calls (for reference, I've made a Visual Studio solution documenting different ways of doing this - you can download that at the bottom of this post).  Lots of projects have some kind of requirement stating only certain people can call certain service operations - for example, you might only want people with a valid username/pw-combination to be able to call your operations, instead of letting everyone call them.  Seeing your servicehost will probably be publicly available (again, unless you're working in an intranet-environment),  anyone could potentially write a client to communicate with your services.  This obviously poses some serious risks.

So, on to username authentication on your service operations.  The idea is that you will require every service call to provide you with a username/pw-combination.  In the service operation, this combination will be validated and  the call will only continue if the combination is valid.  Thus blocking off everyone who hasn't got a valid  combination from using your services! Since we're using SSL/https to encrypt our message, we can safely send the username/pw over the wire.  A comparable method already exists out of the box with WsHttpBinding, but in  Silverlight, we're limited to basicHttpBinding, so we can't use that one.

This project shows different ways of implementing this:

• No authentication.  This is a regular service call, everyone will be able to call the service, no username/pw is passed or sent over the wire, no authentication is done.  This is, obviously, not secure, and shouldn't be done outside of a controlled environment.
• Authentication through method parameters. Username/pw are provided via parameters to the service method. Authentication is done in the service method.  This will work, but it isn't exactly a beautiful solution: all your service method signatures will have to have 2 additional parameters: username & pw.
• Authentication through message headers. Instead of passing the username/pw to the method via parameters, they are passed by adding them to the message header of the message which is sent over the wire. Once in the service method, they are extracted and authentication is done.  This is already a lot better than the previous method: no additional parameters are required.
• Authentication through message headers by implementing an operation behavior. Same as the previous method, but instead of writing code in every method to check username/pw, we write this code once in a custom operation behavior. Every method decorated with this attribute will automatically perform username/pw authentication. This is the preferred way to implement username/pw authentication.

Conclusion: nice code, not too much clutter, encrypted messages & safe calls! :-)
For those of you who want to read more about this (and then some), I got A LOT of help from the reference made by David Betz - give it a read if you find the time.

As usual, full source code is included.  You can download that here.  Enjoy!