IEEEXtreme – The Most Awaited Coding Competition

Xtreme

Register at IEEE UoM for Proctors

Visit IEEEUoM

IEEEXtreme is a global challenge in which teams of IEEE Student members, supported by an IEEE Student Branch, advised and proctored by an IEEE senior member, compete in a 24-hour time span against each other to solve a set of programming problems. The competition made its first appearance in 2007. The Institute of Electrical and Electronic Engineers (IEEE) is the pioneer behind organizing this colossal event.

The Institute of Electrical and Electronic Engineers, which celebrates the 130th anniversary this year is the world’s largest professional organization for advancement of science and technology with around 400,000 IEEE members in over 160 countries around the world. It is the leading authority in many disciplines of engineering including Electronic Engineering, Electrical Engineering and Computer Science & Engineering. There are around 1900 IEEE student branches in 80 countries, across 5 continents in the world.

How Will It Happen..?

IEEEXtreme is organized globally by IEEE (Institute of Electrical and Electronic Engineers) supported by local student branches to host it within local universities.

IEEEXtreme in University of Moratuwa will be organized by IEEE Student Branch of University of Moratuwa within the university premises, gearing up everything including logistics, foods and beverages for coding students to take up challenges and hoist the flag of the university on the top of the ranking board.

The competition will start on 18th October at 05.30 am and end at 05.30 am on the following day, parallel to international event. Students will be given 15 – 20 toughest algorithmic questions issued periodically by the IEEEXtreme global committee. Students will submit the answers on the coding platform provided by IEEE.

IEEE student branch of University of Moratuwa has the responsibility of providing food and beverages and other needs of coding students to place the university on top of the rankings.

We are that close…

IEEE Student branch of University of Moratuwa have been the most consistent student branch of IEEEXtreme programming competition ever since the first time of its appearance in IEEEXtreme 3.0 – 2009 in which they became the global champions. Since then UoM has dominated the competition by producing top ranked teams in large numbers.

 

Year

Best performances

2009 Xtreme 3.0

Global champions

2010 Xtreme 4.0

Rank 11

2011 Xtreme 5.0

Rank 2

2012 Xtreme 6.0

Rank 3 (10 teams in top 100)

2013 Xtreme 7.0

Rank 12 (7 teams in top 100)

 

Apart from the results, IEEE Student Branch of University of Moratuwa is among the largest student branches in the world and the largest student branch in Sri Lanka, exceeding 400+ member base. Also, it is at the forefront of the student branches of largest number of IEEEXtreme participants.

The Grand Prize

The grand prize to the winning team from IEEE headquarters is a trip to any IEEE conference at anywhere in the world, that the team would like to participate in plus the ultimate glory.

From Previous Glory…

10424976_819098498124333_4243584617661961634_n

And we believe it’s time to bring the glory back to University of Moratuwa…

Wanna hear more..? Drop a mail to infoATieeeuomDOTnet

Request for SAML tokens with WSO2-STS

WSO2 Security Token Service is shipped as the Resident Identity Provider of WSO2 Identity Server. The responsibility of a Security Token Service (aka STS) is to provide tokens that are trusted by a relying party to a requester – the service consumer.

There is a terminology goes with the article :

  • RST – Request for a Security Token. This is the initial request sent by a requester to a STS requesting for a security token. Basically This is a XML tag introduced at ws-trust specification.
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
  • RSTR – Response for a Security Token Request. This is the response issued by the STS along with a signed security token to the requested party.
<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
  • Claim – A statement made about something. ie : <email>client@example.com</email> is a claim about client’s email address.
  • Relying Party : The service provider who is trusting the security token service. In the picture ‘Web Service’ (I preferred to call it as ‘Relying Party’ since STS is also a service provider as well as a web service which can be described with WSDL)

The Big Picture

image002

The communication paths are showed by arrows.

  1. requester may grant a security token by sending a RST to the STS or from a third party.
  2. Then the token is submitted to the relying party to access it’s services.
  3. The Web service either trusts the issuing security token service or may request a token service to validate the token (or the Web service may validate the token itself).

Simulation

Lets simulate the scenario with WSO2 identity Server. According to the specification there are three parties communicating to each other trusting each other. The cast crew in the real world will be,

  • STS – WSO2 Identity Server’s resident identity provider (WSO2 STS)
  • Relying Party  – Echo Service of WSO2 ESB
  • Requester – STS Sample Client

Run WSO2 Identity Server on the default port (9443). Please refer Getting Started guide to download and run the product.  Please note we are using the latest version of Identity Provider which is IS 5.0 at the moment. The directions may be differed according to the version.

Move to Resident Identity Provider from Main > Identity Providers > List > Resident Identity Provider

Then set inbound authentication properties by giving username token to authenticate requesters before issuing tokens. Then we can secure the STS from issuing tokens to every Tom, Dick and Harry who send RSTs.

Workspace 1_019

Go to Apply Security Policy and select UserNameToken (In this security Scenario, the requester should submit a username and a password to in order to get a security token. As described in WS-Security. By default username and password are similar to management console user name and password which are “admin”,”admin”).

Add all user groups from the next window and click finish.

Running the Requester

But.. wait.. Where is the service? Here we can run the STS client without setting the relying party in IS in order to grant a security token. It is not necessary to have a relying party to grant the security token from the STS.

Checkout the client from here.

The client code is written to send RSTs to a given end point defined at src/main/resources/client.properties
By default

https://localhost:9443/services/wso2carbon-sts

is the service URL of the STS if you have started the IS on default port.

Without changing other properties you can safely run the client via shell script located at sts-client folder via

sh sts-client.sh

command. It will print the received SAML assertion on the terminal. You also can view the RST and RSTR on the SOAP tracer of the management console of Identity server.

Changing the Client Properties

Client configuration can be changed using the client.properties file which is located at dir src/main/resources

Quick look at the property file

You can change the relying party address (which we didn’t use here) from here. Here end point URL of the WSO2 ESB echo service has been given.

address.relyingParty=http://localhost:8281/services/echo

SAML version of the RST can be changed from here. (Depending on the version, SAML assertion issued from the STS will be changed)

saml.token.type=2.0

Username and password for UsernameToken security policy

ut.username=admin
ut.password=admin

 

End of the SoC, but the passion remains the same

That was a great period to remember for a life time. Reading, Coding, again reading, refactoring, some annoying issues (things get really annoyed when you update the local repository during a bustage ;) but still there was a lot of things to learn), getting reviews from experts..!!

I really enjoyed the SoC and hoping to continue contributing to internet giant Mozilla. There are few knits I still have to fix on patches and will be working on them in future as well. I got to know that fake server was something important to calendar so I will be focusing more into it and then fixing other proposed issues which were left behind due to sudden intrusion of the fake server.

Variations from the proposed deliverables as I decided with Mohit:

  • Week 3: Patch for schedule-calendar-transp
    Dropped since it requires some UI related changes
  • Week 4 – Week 6: Patch for If-Schedule-Tag and If-Schedule-Tag-Match
    Patch is done, needs to be made reviewable & handle edge cases
  • Week 6- Week 7: Patch for schedule-default-calendar-url
    No need to implement in lightning since this is more of a property that will allow clients to manage calendar collections for one user. More suited to a dedicated client for a particular server.
  • Week 7- Week 8: Patch for min/max date-time
    That is something related to the server, and is not returned in a PROPFIND request.
  • Week 8- Week 9: Patch for max-attendees per instance
    UI Changes required
  • Week 10 – Week 12: Unit tests for schedule-tag
    On track, this evolved into a major chunk of the project, with the fake server implementation and its design to support overriding, a rough working patch is completed, a more robust implementation in the works.
  • Week 12- Week 14: Mozmill tests for invitation scenarios
    This has been completed. Just some minor cleanup required with the packaged test thing.
  • Week 14- Week 15: Patch for schedule-force-send
    Needs UI change became less of a priority.

On the way, fake server became something that took a long time since it was a RFC implementation rather than a modification.

Throughout the GSoC period I received a great mentoring from Mohit, so herewith I’d like to give my gratitude to him for all the time he allocated and being cool throughout the period. Also, to Philipp for all the tech reviews. Without them I’d never caught up the complex things in the codebase.

Fun Facts :

Well, If you are going to contribute to Mozilla TB or Lightning by any chance lol, you should probably know these two abbreviations. You can’t find them in Google anyway.

m-c and c-c : I drove into trouble several times by hearing to update m-c and c-c. I was thinking that is something related to changset headers and hashes. well at last got to know, they weren’t. Those were the two folders named “mozilla-central” and “comm-central” in the repository.

PS: I searched in google for the term “c-c and m-c revisioning” and got the result “Women’s Choices Within Market Constraints: Re-Visioning;)

I will update the blog with my future works related to Lightning as well.

Cheers!

Fake Server – New Structure

There were a structural change in the fake server test I had to do before I submitting my last patch. Now the fake server is not merely a test and it can be extended by child classes to create desired types of server classes to be tested. Also I added a random e/schedule tag generator for events and memory calendar meta data API to keep them in the server. Hopefully, This will pretty much cover basic requirements of a fake server and can test the schedule tag as we expected. Schedule-Tag test and fake server class will go as two separate deliverables and schedule tag test will be based on the fake server class.

Fake server test : contd

The error raised in the PROPFIND block could fixed with the help of Philipp. It was due to wrong sequence of initialization messages to the calendar. To initialize a CalDav calendar properly, a sequence of asynchronous messages need to be sent.

  1. Initial PROPFIND response
  2. OPTIONS response
  3. PROPFIND response for user address set
  4. PUT request and response
  5. REPORT response

After properly sending messages, the calendar could initialized with items. Added responses and configurations in js objects, so server configurations can be changed easily.

github link for the test :
https://github.com/Malintha/gsoc-14/blob/master/test_fakerServer.js

After the initialization of the calendar properly, I’m moving on with adding schedule-tag and if-schedule-tag-match test cases to the code.

Schedule-tag changes are evaluated on 2 scenarios.

  1. Changes to Organizer’s object resource
  2. Changes to Attendee’s object resource

For organizer’s changes, schedule-tag may or may not be changed on the type of the change.
[Refer http://tools.ietf.org/html/rfc6638#section-3.2.10]

  1. If the organizer changes the ical object with a PUT request, schedule-tag of the organizer’s object should be changed and changes should be merged with attendee objects[1].
  2. Schedule tag will not be changed as a result of processing an attendee PARTSTAT change response.

For attendee object resources there are three cases affect to the schedule tag.

  1. [1]Schedule-tag should be changed after processing updates from the organizer which contains updates more than other attendees’ PARTSTAT changes.
  2. Schedule-tag should not be changed after processing updates from organizer which only contains PARTSTAT changes of other attendees[2].
  3. Schedule-tag should be changed after processing HTTP requests like PUT,COPY,MOVE from the attendee himself.

It took me sometime to understand the scenario from the server perspective. [2]I’m not sure is it jumping into a prejudgement by understanding that, according to 2nd case about attendee’s schedule-tag change, server leaves attendees outdated by not letting clients updated after processing changes from other attendees.

On the implementation, I’m implementing the organizer scenario first with changes to the object resource. Implementation goes like following.

  1. change the existing calendar item(date/time, summary)
  2. send the changed item to the calendar by cal.modifyItem(Item,oldItem,listener)
  3. merge the change with attendee object resource and update the schedule-tag after PUT request
  4. reply to the multistatus message with new schedule-tag
  5. assert client’s item and servers item to make sure both are similar

Cheers!

Mid Term Passed – Game on its course

Mid term evaluation results were posted on yesterday by Google and I have passed! Cheers! :)

Last week was kind of a milestone of fakeserver test journey. I could establish the communication between the calendar and the test successfully and transmit upto multiget request between the calendar and the test.
The test up-to now.
Currently the test has 2 path handlers.

  • A calDav calendar was created on http://localhost/calendar and a handler was created to manage requests coming to that path.
  • A path handler to serve requests to the event url which is http://localhost/calendar/event.ics

Sequence of messages flow between the test and the calendar.

  1. Test sends addItem() message with PUT method to the calendar.
  2. Calendar sends back a multiget message to retrieve calendar data with REPORT method.
  3. Test serves the multiget request with Schedule-tag and, etag, href address and the actual calendar data. (Now, this is where I currently stopped. multigetRequestHandler’s SAXparser throws a fatal error at the response which is believed to be due to an error with wellformness of the response.)

Here onwards things have to be dealt with cautious. After move onto add the item successfully to the calendar, operations which the schedule-tag involved in have to be implemented. For that, schedule-tag needs to be calculated according to the RFC standards. Already created the method for schedule-tag manipulation, but definitely needs more situations handled when things move on.

I use wireshark to capture the packets which are being transferred between two endpoints. This is a screen shot of the first win. :)

Firstwin

Another todo : Needs to move handler functions to separate .sjs files for more clarity. But at the moment I thought to move on leaving them in the test file.

Fake Server Test : contd

It has some serious operations! Since the server needs to provide functionality to Create/Modify/Delete operations on requests, the logic behind the RFC standard operations needs to be embedded in the server backend.

During the test, server is created on localhost:50001 (I used the particular port, so it is easy to trace packets when comes to debugging) and requests are sent to specific URIs.

ie: create operation may send a request to <BASE_URL>/create/event.ics with PUT header. Also, If-None-Match : * header specified. We assume there are no conflicts with other files and etags are manipulated perfectly. Since the server is not a real file container, instead of creating temp files at the runtime (for new resources) and bind to the URL, an ics file will be registered to a URL and will be served by <BASE_URL>/create/event.ics url.

Once the file is asserted existing, the server will return 201 status code, etag and the schedule-tag. Calendar needs to keep them stored.

I spent the last week getting familiar with httpd.js, NSIHTTP* api and other test, util modules. I could create the basic handler functions and listeners needed to manipulate requests/responses. I found using wireshark to capture packets travel between two parties very helpful to move forward with the test.

My next target is to handle various requests on various URLs and treat them accordingly.

Unit Testing

It is time for testing. We decided that the test needs to be a unit test which can more generally surpress  calendar operations, with sequence of message injections.

That way we can make sure calendar operations are taking place according to RFCs and reacts to predefined behaviour according to given responses. XPCshell based unit test will provide preloaded response data imitating various CalDav server behaviours.

Unit test will basically create a temporary HTTP server on localhost using httpd.js. Calendar will send sync requests to the server and server will respond to them with different response data. Calendar reactions will be asserted against expected values.

As we decided, the test needs to be modular enough to mimic behaviour of different CalDav servers and changing the response data easily. The most challenging thing would be bringing the modularity to the test.

The test will contain :

  • Send initial PROPFIND request
  • Send multistatus requestto get hrefs of events
  • Send multiget request
  • Inject calendar data
  • Assert for schedule-tag and etag values

Along with If-schedule-tag-match

It was another patch for schedule-tag with support to If-Schedule-Tag-Match property. I made Schedule-Tag property implementation  more pluggable, so it makes the isScheduleTagSupport attribute true at startElement() of SAX parsing if the server returns Schedule-Tag value and then proceed.

To support If-Schedule-Tag-Match, it was needed to change the If-Match request headers in DELETE, MODIFY operations in to If-Schedule-Tag-Match. But possibly still some servers don’t support processing Schedule-Tag. Therefore I added lines to check if the response contains the schedule-tag before setting the request header. If not, it continues with the usual Etag comparison.

If the schedule-tag value belongs to the response is in the mItemInfoCache, there is no possibility that the server not support the header.

Still a lot of testing has to be done on the implementation, though it looks simple, it involves in all critical operations.

I hope to work on adding few more functionalities to the mozmill test for the imip-bar and more testing on schedule-tag implementation on next couple of days.

Cheers!

Multiget, multiget everywhere!

I spent last days going through sequence of handler functions and understanding at what points I should query for schedule-tag from the server.

There are 3 handlers in the calDavRequestHandlers.js

etags handler
webdavSync Handler
multigetSync Handler

Each handler parses the retrieved xml REST message with nsiSaxParser. At the end of parsing, [when reached to endDocument() function], it calls doMultiget() with a set of items that are identified need fetching.

If an item detected which was deleted, newly created or updated from etags it will be added to the list, itemsNeedFetching{}.

Items will be fetched in doMultiget().

So I decided adding the query, <C: schedule-tag> within multiget would do the thing. (WebDav sync doesn’t return a schdule-tag anyway)

Then the schedule-tag will be added to the list, mItemInfoCache with respected UID with  property name “scheduleTag” (I removed the hyphen in middle of the Local name). This may cause to add a null value for the mItemInfoCache[item.id].scheduleTag and I will manage it in If-Schedule-tag-Match property implementation.

I think this will pretty much cover the retrieval of schedule-tag property.

I found another regression in the code, which spoof the OPTIONS request when dealing with Google calendar.  I found that currently with CalDav v2, Google supports OPTIONS method. So there won’t be any need to spoof the method.  I’ll put this in my todo list as well.

My next step is implementing if-schedule-tag-match property.