Saturday, October 31, 2009

Security in the Directory Layer

After brainstorming for a while I came up with an idea for the security stuff in the directory layer.

In the existing code it's referred to as an access list.

Basically different resources are registered with the Directory layer. Each resource has an access list which is basically an user id associated with a permission.

Right now the access is an int8_t with the following constants defined for identifying what each value represents:


 static const uint8_t  READ_ACCESS        = 0x01;
 static const uint8_t  WRITE_ACCESS       = 0x10;
 static const uint8_t  READ_WRITE_ACCESS  = 0x11;
 static const uint8_t  NO_ACCESS          = 0x00;


What identifies the resource is a simple std::string object. This makes it flexible enough so that we can provide this functionality to utility developers and new resources can be created at run-time without creating conflicts.

However, because of this we will need to enforce a naming convention for resource names. This will need to be enforced by only allowing utility developers to create resource access lists through our API.

The naming convention should probably be something like this:
- For server resources: "server_resource"
- For workspace resources: "workspace_workspacename_resource"
- For workspace resources created by utilities: "utility_workspace_utilityname_workspacename_resource"

ie: In the Directory database in trunk there is an existing resource called "server_add_new_user". This is a resource that is used to determine who can add new users to the server.

In this case, a read access would only allow to see who has access to the resource, and a write access would allow to actually use the resource (Add new users to the server).

There is one more thing that we've talked about which is Server and WorkPlace roles. I haven't implemented this yet, but I have a good idea of how to do so (probably sometime next week).

I think the Role code should be more like a script (not literally of course). All it will do is know how to give the person the role is given to, the right access, to the right resources. So if a role of Server Administrator is applied to a user, then the Role code will give the user read/write access to most server functionalities, such as stopping the server (server_stop), restarting the server (server_restart), adding new users (server_add_new_user), etc... This should be easy to implement. We just need to find out what resources to give access to for each Role.

Monday, October 12, 2009

Mira connects to peers on LAN

Ok... so it wasn't as easy as I thought to get the network code going for p2p. I think the discovery part was actually easier.

Either way I do have something to show:















What you see is my regular laptop (clsk@aliensoft (192.168.0.3)) + a virtual machine (aalvarez@alientest (192.168.0.4)) both running a Mira client. You can see that they discover each other and connect to each other as well.

Right now, they create two connections when they discover each other, but I've already got a system down so that they chose which one will connect just haven't implemented it yet. Also, I haven't integrated it to the GUI just yet, but that will be the easy part.

Either way, that's the final product of long hours of scratching my head, trying to figure out how Avahi really worked and re-designing the network code. There's a lot Mira will be able to do from here. Getting Mira to do what Giver does is just a matter of implementing drag&drop and sending the files through the connection already established.

Also, the network code is multi-threaded. Right now the whole application runs 5 concurrent threads which is more than enough. So for those that have multi-core processors, Mira will take advantage of them.

Update: Here's a screenshot with the ContactDockWidget userlist being updated when a connection with a Neighbor (P2P) is established.















Also, I've created a new branch in launchpad for this code called p2p. This will live there until I can port the code to Windows and OS X

Sunday, October 11, 2009

Service discovery on the LAN on Mira

So I don't have much to show, but here is something...



This means the Mira client application can register its own peer-to-peer service and discover other clients on the network.

There's some more to do before I can actually show some useful screenshots. Mainly re-doing the client networking code. Shouldn't be much work since I'm just going to use the Server's network code as a template. Like I did before, but this time taking into account the fact that the client is somewhat of a server as well.

By the way, this only works on linux so far. I plan to do a version using Bonjour so it'll work on windows and Mac OS X. So for now I'll be posting to a separate branch.

Saturday, October 10, 2009

Restarting Mira development

Another project I used to work on, and plan to start working on again is Mira Groupware.

Its development has been inactive for some time, but that won't be for long.

After watching a video on Giver (an application developed by a Novell programmer), it motivated me to start working on it again.

Giver is a great application, and I suppose it does what it is supposed to do, but it has so much potential. However, development for it has stopped completely as it was just a weekend (or week-long) project. I could just expand Giver, but I don't think it was designed to do all the things I have in mind. Which Mira Groupware is. The network code for Mira has been ready for a long time. I'm now working on the Zeroconf (service discovery) on linux using Avahi (the same library Giver uses).

Hopefully I'll have some screenshots to show in a few days/weeks.

Friday, October 9, 2009

libmapi++ not header-only for long

So after trying to clean up the code in the Akonadi Resource it seems like libmapi++ is not going to be a header-only library much longer.

Either way, the main reason for keeping it that way was to make it easier for other people to use. Now that libmapi++ is part of the openchange build-system, and it's distributed as part of the openchange distribution, that is not really needed anymore, because it gets "built" anyway.

However, that's going to be in the near-future. First I want to concentrate in getting the resource stable and working with the current version of akonadi and whatever client is able to access it (which I'm still trying to figure out).

After a quick trial, Mailody seems not to be very up-to-date with Akonadi development. So right now I'm trying to figure out what to use to test the resource.

Thursday, October 8, 2009

Brad Hard's OpenChange/Akonadi Talk

Here's a link to Brad Hard's (My GSoC Mentor) talk on OpenChange and Akonadi:

http://www.kdedevelopers.org/node/3905


So How Was GSoC 2008 after all?

So I never used this for GSoC. It's actually been a while since I got accepted and finished GSoC.

So I'll tell a brief story of how it went.

After being asked to decide for one of the two projects, I decided to go with the Akonadi OpenChange resource. I would say that the biggest factor was the fact that I already had a relationship with who would be my mentor before I was even accepted. But I was very interested in both projects.

The summer went well, and I accomplished almost all tasks of my project.

You can see most of what I accomplished here.

After the summer ended I redeployed from Iraq back to the U.S.
I've also moved a lot of times since then, so I never really had a chance to completely settle down until now.

So now that I'm somewhat settled down, I've decided to start working on the Akonadi openchange resource again. Most of what is left is sending information to the Exchange server, as I almost finished pulling information from it during GSoC.

I've already fixed an annoying bug that made the resource crash when an openchange profile database wasn't created (which is the case for all new users).

The bug slipped by because I always had a profile database while I was working on the resource before. I guess starting all over again brought something good to the table :).

So, After installing MS Exchange 2008 R2 Preview, I found out that you can't install Exchange server in it, so now I'm going to try and install MS Exchange Server 2008 (not the R2 version) and see if that works.

I hope to start using this again to keep people updated.