FitProgrammer@Work: October 2013

Wednesday, October 30, 2013

Installing Groovy & Grails on Linux

GVM is a tool for managing parallel Versions of multiple Software Development Kits on most Unix based systems. It provides a convenient command line interface for installing, switching, removing and listing Candidates.

GVM was inspired by the highly useful RVM and rbenv tools, used at large by the Ruby community.

Candidates that are currently supported are:

Gaiden
Groovy
Grails
Griffon
Gradle
Groovyserv
Lazybones
Spring Boot
vert.x

Groovy REST Client

Using RESTClient for Groovy - http://groovy.codehaus.org/modules/http-builder/doc/rest.html

Example code:
package restclient

import groovyx.net.http.RESTClient
import static groovyx.net.http.ContentType.JSON

restClient = new RESTClient( 'http://localhost:8080/CustomerDB/webresources/', JSON)
def resp = restClient.get(path: 'entities.customer')
assert resp.status == 200
println resp.data
def respHeaders = resp.getAllHeaders()
respHeaders.each { header ->
println header
}

Tuesday, October 29, 2013

Groovy By Example: For Java Programmers

This is based on - http://www.infoq.com/presentations/Groovy-for-Java-Programmers

Groovy is a JVM scripting language, it supports dynamically typed variable, comes with groovyc (interpreter), groovyConsole (small Swing editor). It interoperates with Java seamlessly - can call any Java method and use any Java class. The same holds true for Java - it can call into groovy scripts.

Example 1:
class GroovyPerson {
// dynamically typed - no semi colons needed.
def age
// statically typed
String name

def printName() {
println name
}

static void main(String[] args) {
// default constructor can accept any number of properties - no getters/setters
def person = new GroovyPerson(age:7, name: 'Jake')
person.printName()
}
}

Example 2:

def cal = Calendar.instance
cal.clear() -- parens required if not passing params to a method
cal.set Calendar.MONTH, Calendar.JULY -- parens optional if passing params to method.
cal.set Calendar.DATE, 4
cal.set Calendar.YEAR, 1776

def time = cal.time

println time

Change 2 to Example 3:
def cal = Calendar.instance
cal.with { -- with() method is added to all classes in java because of groovy to support this usage.
clear()
set MONTH, JULY
set DATE, 4
set YEAR, 1776
println time
}

with {} method on an object lets us remove cal. from within the with block.

Everything is Groovy is an object.
Example 4:
result = 10
println result.class

outputs: class java.lang.Integer

Example 5:

aString = 'This is a string' -- a regular String is single quoted

answer = 42

aGString = "The answer is $answer" -- a GString (may contain embedded groovy code) is double quoted

Example 6:

message = 'Groovy Is Cool' --- last character in string is -1 index, first is 0 index.

println message[0] //G

println message[-4] // C

println message[0..5] // Groovy

println message[-4..-1] //Cool

println message[-1..-4] // looC -- substrings can be gotten with ranges

Example 7: List
names = ['Watsh', 'Manish', 'Saket']

println names.class -- java.util.ArrayList.
names << 'Rahul' //-- add to the list
println names

Example 8: Maps
myMap = [name:'Watsh', language: 'Groovy']
myMap.town = 'San Ramon' -- put value in map for town key
myMap['company'] = 'Brocade' -- put value in map for company key

println myMap.getClass() -- java.util.LinkedHashMap (default)

println myMap.company

Example 9: Class - no getter/setter for properties
class BaseballTeam {
def city
def team

def getDisplayName() {
"$city $team"

}
}

myTeam = new BaseballTeam(team: 'Bulls', city: 'San Ramon')

println myTeam.team
println myTeam.city
println myTeam.getDisplayName()

Example 10: Closure
myClosure = {
println "This is closure object $it" -- 'it' is implicit object for a closure.
}
3.times myClosure -- times() method on Integer can take a closure and invoke it n times.

outputs:

This is closure object 0
This is closure object 1
This is closure object 2

Return statement is optional. If no return statement found, the last statement in method is evaluated and returned.

Example 11: More Closure
// passing argument to closure
3.times {firstArg ->
println "The argument is $firstArg"
}

// using closure to iterate a hashmap
data = [company:'Brocade',
name: 'Watsh']

data.each {key, value ->
println "$key is $value"
}

Installing Oracle JDK on Ubuntu

JDK version 1.7.0 update 45
Linux Mint 15 x86-64

Reference: http://www.wikihow.com/Install-Oracle-Java-JDK-on-Ubuntu-Linux

Remove OpenJDK

sudo apt-get purge openjdk-\*

sudo mkdir -p /usr/local/java
sudo cp -r jdk-7u45-linux-x64.tar.gz /usr/local/java
cd /usr/local/java
Extract the archive:

sudo chmod a+x jdk-7u45-linux-x64.tar.gz
sudo tar xvzf jdk-7u45-linux-x64.tar.gz

Create a symbolic link as: jdk7 -> jdk1.7.0_u45

sudo ln -s jdk1.7.0_45 jdk7

This is so to avoid doing all the steps when the next time we update the jdk then we just change the jdk7 symbolic link to point to the then latest jdk.

Add JAVA_HOME to PATH environment variable:

sudo gedit /etc/profile
Paste and save:

JAVA_HOME=/usr/local/java/jdk7
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
export JAVA_HOME
export PATH

Inform Linux system where Oracle JDK is located:

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/local/java/jdk7/bin/java" 1
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/local/java/jdk7/bin/javac" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/local/java/jdk7/bin/javaws" 1

Inform Linux system that Oracle JDK must be the default Java:

sudo update-alternatives --set java /usr/local/java/jdk7/bin/java
sudo update-alternatives --set javac /usr/local/java/jdk7/bin/javac
sudo update-alternatives --set javaws /usr/local/java/jdk7/bin/javaws

Reload /etc/profile.

. /etc/profile

Test to see if installation is correct:

java -version
javac -version
javaws -version

REST Web APIs - Part 1

This my notes from the book REST Web APIs by Mike Amundsen.

RESTful architectures are designed for managing change.
We all understand hypermedia in the context of the Web. It’s just a fancy word for links. Web pages link to each other, and the result is the World Wide Web, driven by hypermedia. Hypermedia is the single most important aspect of REST, and the least understood.
We say that a URL is the URL of some thing: a product, a user, the home page. The technical term for the thing named by a URL is resource.
When a web browser sends an HTTP request for a resource, the server sends a document in response (usually an HTML document, but sometimes a binary image or something else). Whatever document the server sends, we call that document a representation of the resource.
URL identifies one and only one resource. If a website has two conceptually different things on it, we expect the site to treat them as two resources with different URLs.
The principle of addressability just says that every resource should have its own URL.
Application state is kept on the client, but the server can manipulate it by sending representations — HTML documents, in this case — that describe the possible state transitions. Resource state is kept on the server, but the client can manipulate it by sending the server a representation — an HTML form submission, in this case — describing the desired new state.
The strands of the web are the HTML tags and
tags, each describing a GET or POST HTTP request Alice might decide to make. I call this the principle of connectedness: each web page tells you how to get to the adjoining pages. The Web as a whole works on the principle of connectedness, which is better known as “hypermedia as the engine of application state,” sometimes abbreviated HATEOAS.
You know what application state is — it’s which web page a client is on. Hypermedia is the general term for things like HTML links and forms: the techniques a server uses to explain to a client what it can do next. To say that hypermedia is the engine of application state is to say that we all navigate the Web by filling out forms and following links.
All successful post-Web protocols do something the Web can’t do: peer-to-peer protocols like BitTorrent and real-time protocols like SSH. For most purposes, HTTP is good enough.
The unprecedented flexibility of the Web comes from the principles of REST.
In REST terms, putting information about URL construction in separate human-readable documents violates the principles of connectedness and self-descriptive messages. In REST terms, the website redesign is entirely encapsulated in the self-descriptive HTML documents served by the website. A client that could understand the old HTML documents can understand the new ones.
The HTTP standard says that a GET request is a request for a representation. It’s not intended to change any resource state on the server.
application/vnd.collection+json, you’ll discover that it’s a media type registered for Collection+JSON. Collection+JSON is a standard for publishing a searchable list of resources over the Web. JSON puts constraints on plain text, and Collection+JSON puts constraints on JSON. A server can’t serve just any JSON document as application/vnd.collection+json. It can only serve a JSON object: {} But not just any object. The object has to have a property called collection, which maps to another object: {"collection": {}} The “collection” object ought to have a property called items that maps to a list: {"collection": {"items": []}} The items in the “items” list need to be objects: {"collection": {"items": [{}, {}, {}]}} And on and on, constraint after constraint. Eventually you get the highly formatted document you just saw, which starts out like this:

A typical Collection+JSON will contain a set of links, list of items, a queries collection, and a template object.

{ "collection" :
  {
    "version" : "1.0",
    "href" : "http://example.org/friends/",
    
    "links" : [
      {"rel" : "feed", "href" : "http://example.org/friends/rss"}
    ],
    
    "items" : [
      {
        "href" : "http://example.org/friends/jdoe",
        "data" : [
          {"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"},
          {"name" : "email", "value" : "jdoe@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/jdoe", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/jdoe", "prompt" : "Avatar", "render" : "image"}
        ]
      },
      
      {
        "href" : "http://example.org/friends/msmith",
        "data" : [
          {"name" : "full-name", "value" : "M. Smith", "prompt" : "Full Name"},
          {"name" : "email", "value" : "msmith@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/msmith", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/msmith", "prompt" : "Avatar", "render" : "image"}
        ]
      },
      
      {
        "href" : "http://example.org/friends/rwilliams",
        "data" : [
          {"name" : "full-name", "value" : "R. Williams", "prompt" : "Full Name"},
          {"name" : "email", "value" : "rwilliams@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/rwilliams", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/rwilliams", "prompt" : "Avatar", "render" : "image"}
        ]
      }      
    ],
    
    "queries" : [
      {"rel" : "search", "href" : "http://example.org/friends/search", "prompt" : "Search",
        "data" : [
          {"name" : "search", "value" : ""}
        ]
      }
    ],
    
    "template" : {
      "data" : [
        {"name" : "full-name", "value" : "", "prompt" : "Full Name"},
        {"name" : "email", "value" : "", "prompt" : "Email"},
        {"name" : "blog", "value" : "", "prompt" : "Blog"},
        {"name" : "avatar", "value" : "", "prompt" : "Avatar"}
        
      ]
    }
  } 
}

Collection+JSON is a way of serving lists — not lists of data structures, which you can do with normal JSON, but lists that describe HTTP resources. The collection object has an href property, and its value is a JSON string. But it’s not just any string — it’s the URL I just sent a GET request to: { "collection": { "href" : "http://www.youtypeitwepostit.com/api/" } } The Collection+JSON standard defines this string as “the address used to retrieve a representation of the document” (in other words, it’s the URL of the collection resource). Each object inside the collection’s items list has its own href property, and each value is a string containing a URL, like http://www.youtypeitwepostit.com/api/messages/21818525390699506 (in other words, each item in the list represents an HTTP resource with its own URL).
A document that doesn’t follow these rules isn’t a Collection+JSON document: it’s just some JSON. By allowing yourself to be bound by Collection+JSON’s constraints, you gain the ability to talk about concepts like resources and URLs. These concepts are not defined in JSON, which can only talk about simple things like strings and lists.
To create a new item in the collection, the client first uses the template object to compose a valid item representation and then uses HTTP POST to send that representation to the server for processing.
Collection+JSON works along the same lines as HTML. The server provides you with some kind of form (the template), which you fill out to create a document. Then you send that document to the server with a POST request.
Its template property is the "template object” mentioned in the Collection+JSON specification: { ... "template": { "data": [ {"prompt": "Text of message", "name": "text", "value":""} ] } To fill out the template, I replace the empty string under value with the string I want to publish: { "template": { "data": [ {"prompt": "Text of the message", "name": "text", "value": "Squid!"} ] } } I then send the filled-out template as part of an HTTP POST request: POST /api/ HTTP/1.1 Host: www.youtypeitwepostit.com Content-Type: application/vnd.collection+json { "template": { "data": [ {"prompt": "Text of the message", "name": "text", "value": "Squid!"} ] } }
The server responds: HTTP/1.1 201 Created Location: http://www.youtypeitwepostit.com/api/47210977342911065 The 201 response code (Created) is a little more specific than 200 (OK); it means that everything is OK and that a new resource was created in response to my request. The Location header gives the URL to the newborn resource.
REST is not a protocol, a file format, or a development framework. It’s a set of design constraints: statelessness, hypermedia as the engine of application state, and so on. Collectively, we call these the Fielding constraints, because they were first identified in Roy T. Fielding’s 2000 dissertation on software architecture, which gathered them together under the name “REST.”
A resource is anything that’s important enough to be referenced as a thing in itself. If your users might “want to create a hypertext link to it, make or refute assertions about it, retrieve or cache a representation of it, include all or part of it by reference into another representation, annotate it, or perform other operations on it” (Architecture), you should make it a resource. Giving something a URL turns it into a resource.
When a client issues a GET request for a resource, the server should serve a document that captures the resource in a useful way. That’s a representation — a machine-readable explanation of the current state of a resource.
The server might describe a database row as an XML document, a JSON object, a set of comma-separated values, or as the SQL INSERT statement used to create it. These are all legitimate representations; it depends on what the client asks for. A representation can be any machine-readable document containing any information about a resource. We think of representations as something the server sends to the client. That’s because when we surf the Web, most of our requests are GET requests. We’re asking for representations. But in a POST, PUT, or PATCH request, the client sends a representation to the server. The server’s job is then to change the resource state so it reflects the incoming representation.
The server sends a representation describing the state of a resource. The client sends a representation describing the state it would like the resource to have. That’s representational state transfer.
If a DELETE request succeeds, the possible status codes are 204 (No Content, i.e., “it’s deleted, and I don’t have anything more to say about it”), 200 (OK, i.e., “it’s deleted, and here’s a message about that”); and 202 (Accepted, i.e., “I’ll delete it later”).
If a client tries to GET a resource that has been DELETEd, the server will return an error response code, usually 404 (Not Found) or 410 (Gone): GET /api/
DELETE method has another useful property: it’s idempotent. Once you delete a resource, it’s gone. The resource state has permanently changed. You can send another DELETE request, and you might get a 404 error, but the resource state is exactly as it was after the first request. The resource is still gone.
POST request to a resource creates a new resource underneath it. The most common response code to a POST-to-append request is 201 (Created). It lets the client know that a new resource was created. The Location header lets the client know the URL to this new resource. Another common response code is 202 (Accepted), which means that the server intends to create a new resource based on the given representation, but hasn’t actually created it yet.
A PUT request is a request to modify resource state. The client takes the representation it got from a GET request, modifies it, and sends it back as the payload of a PUT request. If the server decides to accept a PUT request, the server changes the resource state to match what the client says in the representation, and usually sends either 200 (OK) or 204 (No Content). PUT is idempotent, just like DELETE. The client can also use PUT to create a new resource, if it knows the URL where the new resource should live. PUT is an idempotent operation even when you use it to create a new resource.
The PATCH method allows for this. Instead of PUTting a full representation, you can create a special “diff” representation and send it to the server as the payload of a PATCH request.
PATCH /my/data HTTP/1.1 Host: example.org Content-Length: 326 Content-Type: application/json-patch+json If-Match: "abc123" [ { "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } ]
The best response codes for a successful PATCH are the same as for PUT and DELETE: 200 (OK) if the server wants to send data (such as an updated representation of the resource) along with its response, and 204 (No Content) if the server just wants to indicate success. PATCH is neither safe nor idempotent.

Monday, October 28, 2013

XPath Cheatsheet

<root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
 <actors>
  <actor id="1">Christian Bale</actor>
  <actor id="2">Liam Neeson</actor>
  <actor id="3">Michael Caine</actor>
 </actors>
 <foo:singers>
  <foo:singer id="4">Tom Waits</foo:singer>
  <foo:singer id="5">B.B. King</foo:singer>
  <foo:singer id="6">Ray Charles</foo:singer>
 </foo:singers>
</root>

Excerpted from: http://www.freeformatter.com/xpath-tester.html

1. Select the document node

2. Select the 'root' element

/root

3. Select all 'actor' elements that are direct children of the 'actors' element.

/root/actors/actor

4. Select all 'singer' elements regardless of their positions in the document.

//foo:singer

5. Select the 'id' attributes of the 'singer' elements regardless of their positions in the document.

//foo:singer/@id

6. Select the textual value of first 'actor' element.

//actor[1]/text()

7. Select the last 'actor' element.

//actor[last()]

8. Select the first and second 'actor' elements using their position.

//actor[position() < 3]

9. Select all 'actor' elements that have an 'id' attribute.

//actor[@id]

10. Select the 'actor' element with the 'id' attribute value of '3'.

//actor[@id='3']

11. Select all 'actor' nodes with the 'id' attribute value lower or equal to '3'.

//actor[@id<=3]

12. Select all the children of the 'singers' node.

/root/foo:singers/*

13. Select all the elements in the document.

//*

14. Select all the 'actor' elements AND the 'singer' elements.

//actor|//foo:singer

15. Select the name of the first element in the document.

name(//*[1])

16. Select the numeric value of the 'id' attribute of the first 'actor' element.

number(//actor[1]/@id)

17. Select the string representation value of the 'id' attribute of the first 'actor' element.

string(//actor[1]/@id)

18. Select the length of the first 'actor' element's textual value.

string-length(//actor[1]/text())

19. Select the local name of the first 'singer' element, i.e. without the namespace.

local-name(//foo:singer[1])

20. Select the number of 'singer' elements.

count(//foo:singer)

21. Select the sum of the 'id' attributes of the 'singer' elements.

sum(//foo:singer/@id)

Thursday, October 24, 2013

OpenID Connect - OAuth 2.0 with Authentication

Connect | OpenID:
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
'via Blog this'

Single Sign-on with Shibboleth IDP Server

What is Single Sign-on?
Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

Single sign-on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign-on. For example, an environment where users are prompted to log into their desktop, then log into their email using the same credentials, is not single sign-on.

SSO shares centralized authentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.

Common SSO Configurations:

Kerberos based - Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT). Additional software applications requiring authentication, such as email client or intranet portals, etc. use TGT to aquire service tickets, proving user's idetity to the mailserver or portal server and thus does not require user to re-enter credentials.
Smart card based - Initial sign-on requires use of smart card. Smart card-based single sign-on can either use certificates or passwords stored on the smart card.
OTP based - (one time password) - Two-factor authentication with OTP tokens
SAML - Security Assertion Markup Language (SAML) is an XML-based solution for exchanging user security information between an enterprise and a service provider. It supports W3C XML encryption and service provider initiated web single sign-on exchanges. The user is called the subject in the SAML-based single sign-on. The identity provider is the one that provides the user credentials. The service provider trusts the identity provider on the user information to provide access to its services or resources. One such SAML based SSO solution is Shibboleth which we discuss below.

Shibboleth Identity Provider
Shibboleth is one of world's most deployed federated identity solutions. The Shibboleth software implements widely used federated identity standards, principally the OASIS Security Assertion Markup Language (SAML), to provide a federated single sign-on and attribute exchange framework. A user authenticates with his or her organizational credentials, and the organization (or identity provider) passes the minimal identity information necessary to the service provider to enable an authorization decision. IDP only provides authentication and not authorization.
The Identity Provider provides Single Sign-On services and extends reach into other organizations and new services through authentication of users and securely providing appropriate data to requesting services. In addition to a simple yes/no response to an authentication request, the Identity Provider can provide a rich set of user-related data to the Service Provider. This data can help the service provide a more personalized user experience, save the user from having to manually enter data the service requires, and refresh the data each time the user logs onto the service.

The normal Identity Provider process is:

Accept a SAML authentication request from the Service Provider a user wants to access;
Authenticate the user against your organization's existing authentication service;
Collect user data from your organization's existing data stores;
Apply policy to control what data is released to which Service Provider;
Securely transmit the collected information to the Service Provider.

Single Sign-on Steps

Step 1: User accesses the Resource

The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, directs them to the service provider in order to start the SSO process.

Step 2: Service Provider issues Authentication Request

The user arrives at the Service Provider which prepares an authentication request and sends it and the user to the Identity Provider. The Service Provider software is generally installed on the same server as the resource.

Step 3: User Authenticated at Identity Provider

When the user arrives at the Identity Provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the Identity Provider authenticates them (e.g. by prompting for, and checking, a username and password) and the user proceeds to the next step.

Step 4: Identity Provider issues Authentication Response

After identifying the user, the Identity Provider prepares an authentication response and sends it and the user back to the Service Provider.

Step 5: Service Provider checks Authentication Response

When the user arrives with the response from the Identity Provider, the Service Provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g. the user's identifier) available to the protected resource. After this, the user is sent to the resource.

Step 6: Resource returns Content

As in Step 1, the user is now trying again to access the protected resource, but this time the user has a session and the resource knows who they are. With this information the resource will service the user's request and send back the requested data.

Federated Single Sign-on

If you have heard about Shibboleth you have probably also heard something about "federations" or "Federated Single Sign-on". The steps above are common to all SSO systems, but some of these systems are designed to only work when the Identity Provider and Service Provider are in the same organization, whilst others are designed to work regardless of whether the two components are in the same organization. Implementations that fall into the later category are said to implement Federated Single Sign-on.
It is not uncommon that a given Service Provider may wish to work with more than one Identity Provider (e.g. commercial services with multiple customers, resources used by researchers at multiple organizations), and likewise a given Identity Provider might wish to work with multiple Service Providers. When a group of Identity and Service Providers agree to work together, this group is called a federation.

There have been security concerns pertaining to Federated SSO (which is gaining alot of popularity in the web sites these days) one example excerpted from Wikipedia is reproduced below:

The problem we see now is that many websites are adopting Facebook’s “Connect” and OpenID to allow for one-click logins to access a website. You sometimes don’t even have the choice of making a separate account on that site, meaning you can’t “opt out” of these SSOs. Sure, your information stays safe with that site, but it’s also stored within a central database under Facebook’s control. While there’s nothing wrong with this, there’s just too much risk involved in putting all your sensitive data from all over the web into one massive identity bubble.

—"Does Facebook Federation Have Your Best Interests At Heart?

Deploying Shibboleth Identity Provider

Install tomcat (or one of the supported web containers) and deploy Shibboleth WAR.
Configure IDP login handler for one of the supported authentication types. Simplest will be to have user authenticated based on their IP address as described here - https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthIP
Configure IDP Server - https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfiguration

Service provider (application requiring SSO) identified as relying party
Generate self-signed certificate for IDP server and import to IDP server’s trust store. Used to enable SSL for tomcat.
Export Service Provider's server certificate and import it to IDP server.
Export IDP server certificate and import it to Service provider server.
IDP server metadata URI (which identifies the URI for the service provider where authentication assertion needs to be sent). For example,

IDP metadata URI - https://:8443/idp.xml
Service provider assertion consumer URI - https:///assertionconsumer

One alternative to Shibboleth (SAML based) is to use OpenID based solution like OpenID4Java, which i will capture in a following post.

Tuesday, October 22, 2013

Python

Python is an interpreted and Object oriented language.

Variable is simply defined as:
my_int=7
my_float=1.23
my_bool=True
my_string = "Always look on the bright side of life!"

Never use quotation marks (' or ") with booleans, and always capitalize the first letter! Python is case-sensitive (it cares about capitalization).

In Python, statements are separated by whitespace (no ; at the end!).

Code needs to be indented by 4 spaces (or a tab).
Ex:
def spam():
eggs = 12
return eggs

Comments begin with # or use triple quotation marks for a multi-line comment.
Ex:
""" Hi there
this is my comment

Long one indeed!"""

Arithmetic operators: +, -, *, /, % and ** (Exponentiation). The ** operator raises the first number, the base, to the power of the second number, theexponent.
Ex:
my_var = 10**2
Ans: 100

Backslash (\) escapes a string with quotes.
Ex:
'Help! Help! I\'m being repressed!'

So if you wanted "Y", you could just type "PYTHON"[1].

String methods: string methods are pre-built pieces of code that perform specific tasks for strings. They are: len(), lower(), upper() and str()
Ex:
print "The value of pi is around " + str(3.14)
+ works as string concat operator but first we need to convert 3.14 (a float) to string using str()

print "The %s who %s %s!" % ("Knights", "say", "Ni")

Getting user input on Console:
name = raw_input("What is your name?")

Using datetime:
from datetime import datetime

now = datetime.now()
print str(now.month) + "/" + str(now.day) + "/" + str(now.year)

Monday, October 21, 2013

JRebel How-to: Using JRebel with JBoss Developer Studio and JBoss AS 7.1 | zeroturnaround.com

Friday, October 18, 2013

Documenting REST APIs

Options are -

Enunciate - http://enunciate.codehaus.org/
Swagger - https://developers.helloreverb.com/swagger/
WSDL 2.0 - http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
WADL - http://en.wikipedia.org/wiki/Web_Application_Description_Language
RAML - RESTful API modeling language

Tuesday, October 15, 2013

implementing-rest - Exploring the implementation aspects of the REST architectural style. - Google Project Hosting

implementing-rest - Exploring the implementation aspects of the REST architectural style. - Google Project Hosting:

This is a place for exploring aspects of implementing applications using the REST architectural style. This may include statements about existing frameworks and libraries, general discussions about the nature of the style and how it may be expressed and/or encouraged via a programming framework, etc.

Featured Content

We've started a list of available REST Frameworks

'via Blog this'

Code::Blocks IDE

Code::Blocks:

An open source IDE i started playing with today. Its fast, beautiful (neat syntax highlighting) and the best thing i liked so far is the code completion unlike i had ever seen before for C/C++ IDE. It also claims to be pretty fast in doing builds and debugging.

'via Blog this'

Sunday, October 13, 2013

Best Practices for Speeding Up Your Web Site

Make Yahoo! Web Service REST Calls - YDN

RESTful API Design

Excerpted from: https://blog.apigee.com/detail/api_design_third_edition_video_slides

Source: http://www.blinksale.com/api/: All response codes are included in the HTTP Status response header. Possible status codes include:
·         200: Success (upon a successful GET, PUT, or DELETE request)
·         201: Created (upon a successful POST request)
·         400: Resource Invalid (improperly formatted request)
·         401: Unauthorized (incorrect or missing authentication credentials)
·         404: Resource Not Found
·         405: Method Not Allowed (in case some HTTP method of GET/POST/PUT/DELETE is not supported for a given URI).
·         406: Not Acceptable

·         500: Application Error

Friday, October 11, 2013

SPDY Protocol - Road to HTTP/2.0

Its been 13 years since HTTP/1.1 version came into being (in 1999) and has wonderfully managed to keep up with the pace of development and growth in web usage and technologies.

SPDY Protocol (by Google) proposes to enhance HTTP 1.1 by bringing to the table these new core concepts to web delivery:

Multiplexing (allowing multiple requests to flow over a single connection)
Prioritization (providing the ability to indicate that one resource is more important than another and should hence jump to the head of the line)
Compression (making compression universal and extending it to headers)
Server Push (allowing the server to give content to a user-agent before it is asked for)
A strong recommendation for encryption (current implementations require it) - dropped from HTTP/2.0

IETF started HTTP/2.0 standards effort based on the proposals from SPDY protocol (as starting point). If everything goes well and according to the working group's stated goals, HTTP/2.0 will be faster, safer, and use fewer resources than HTTP/1.1.

HTTP/2.0 is still a ways away. The httpbis working group is targeting Fall of 2014 for a final draft of the protocol.

Understanding REST

The following is excerpted from: http://rest.elkstein.org
What is REST?
REST stands for Representational State Transfer. It relies on a stateless, client-server, cacheable communications protocol -- mostly, the HTTP protocol is used. REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines. REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations. Thus, REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.).

The notion of REST was created in the PhD dissertation of Roy T. Fielding.

Benefits:
REST architecture has all the benefits of Web Service:

Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
Language-independent (C# can talk to Java, etc.),
Standards-based (runs on top of HTTP), and
Can easily be used in the presence of firewalls.

Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP (like use https and use of basic auth etc).

One thing that is not part of a good REST design is cookies: The "ST" in "REST" stands for "State Transfer", and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.

Example:

To lookup a user by ID, REST URI is:

http://www.acme.com/phonebook/UserDetails/12345?firstName=John&lastName=Doe

This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data. If you need to pass long parameters, or binary ones, you'd normally use HTTP POST requests, and include the parameters in the POST body.

It is a common convention in REST design to use nouns rather than verbs to denote simple resources.

Real- world REST API docs:
1. Twitter - https://dev.twitter.com/docs/api - They use only GET and POST (used for create/update/delete).

For create - https://api.twitter.com/1.1/direct_messages/new.json
For Delete - https://api.twitter.com/1.1/direct_messages/destroy.json

2. Amazon S3 - http://docs.aws.amazon.com/AmazonS3/2006-03-01/API/APIRest.html
3. Google Glass' Mirror API - http://www.youtube.com/watch?feature=player_embedded&v=JpWmGX55a40
4. Facebook - https://developers.facebook.com/docs/reference/apis/
5. LinkedIn - http://developer.linkedin.com/apis

Close Job - DELETE - http://developer.linkedin.com/documents/closing-job
Post Job - POST - http://developer.linkedin.com/documents/posting-job
Edit Job - PUT - http://developer.linkedin.com/documents/editing-job
Lookup Job - GET - http://api.linkedin.com/v1/jobs/1337:(id,company,posting-date)

Components of REST Architecture:

Resources - identified by logical URLs. Resources are the key element of a true RESTful design, as opposed to "methods" or "services" used in RPC and SOAP Web Services, respectively. You do not issue a "getProductName" and then a "getProductPrice" RPC calls in REST; rather, you view the product data as a resource -- and this resource should contain all the required information (or links to it). Whenever relevant, a resource should contain links to additional information -- just as in web pages.
There is no connection state; interaction is stateless (although the servers and resources can of course be stateful). Each new request should carry all the information required to complete it, and must not rely on previous interactions with the same client.
Resources should be cachable whenever possible (with an expiration date/time). The protocol must allow the server to explicitly specify which resources may be cached, and for how long. The HTTP cache-control headers are used for this purpose.

Design Guidelines:

Queries should not return an overload of data. If needed, provide a paging mechanism. For example, a "product list" GET request should return the first n products (e.g., the first 10), with next/prev links.
GET access requests should never cause a state change. Anything that changes the server state should be a POST request (or other HTTP verbs, such as DELETE).
Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses.

Another advantage of REST lies with performance: with better cache support, lightweight requests and responses, and easier response parsing, REST allows for nimbler clients and servers, and reduces network traffic, too.

Documenting REST Services:
With version 2.0, WSDL supports all HTTP verbs and it is now considered to be an acceptable method of documenting REST services (WSDL 1.0 only supported HTTP GET and POST verbs).
The second alternative is WADL, the Web Application Description Language which is light weight compared to WSDL and less verbose.

Here is a WADL specification, describing Yahoo "News Search" service:


 1 <?xml version="1.0"?> 
 2 <application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 3  xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd" 
 4  xmlns:tns="urn:yahoo:yn" 
 5  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
 6  xmlns:yn="urn:yahoo:yn" 
 7  xmlns:ya="urn:yahoo:api" 
 8  xmlns="http://wadl.dev.java.net/2009/02"> 
 9   <grammars> 
10     <include 
11       href="NewsSearchResponse.xsd"/> 
12     <include 
13       href="Error.xsd"/> 
14   </grammars> 
15 
16   <resources base="http://api.search.yahoo.com/NewsSearchService/V1/"> 
17     <resource path="newsSearch"> 
18       <method name="GET" id="search"> 
19         <request> 
20           <param name="appid" type="xsd:string" 
21             style="query" required="true"/> 
22           <param name="query" type="xsd:string" 
23             style="query" required="true"/> 
24           <param name="type" style="query" default="all"> 
25             <option value="all"/> 
26             <option value="any"/> 
27             <option value="phrase"/> 
28           </param> 
29           <param name="results" style="query" type="xsd:int" default="10"/> 
30           <param name="start" style="query" type="xsd:int" default="1"/> 
31           <param name="sort" style="query" default="rank"> 
32             <option value="rank"/> 
33             <option value="date"/> 
34           </param> 
35           <param name="language" style="query" type="xsd:string"/> 
36         </request> 
37         <response status="200"> 
38           <representation mediaType="application/xml" 
39             element="yn:ResultSet"/> 
40         </response> 
41         <response status="400"> 
42           <representation mediaType="application/xml" 
43             element="ya:Error"/>
44         </response> 
45       </method> 
46     </resource> 
47   </resources> 
48 
49 </application>

WADL uses type safety using XML schema types.

To author WADL, get the http://www.w3.org/Submission/wadl/wadl.xsd and use a tool that can validate your WADL.xml against the WADL.xsd (one such tool is - XRay XML Editor or you can use http://www.utilities-online.info/xsdvalidation/). Apigee has created a WADL Builder - https://github.com/apigee/WADL-builder

Some REST advocates, however, find even the lightweight WADL to be an overkill. And indeed, most REST services are documented by no more than a textual description (a human-readable HTML file).

Using REST in Java

package rest.client;

import java.io.BufferedReader;

import java.io.IOException;

import java.io.InputStreamReader;

import java.io.OutputStream;

import java.io.OutputStreamWriter;

import java.io.Writer;

import java.net.HttpURLConnection;

import java.net.URL;

import java.net.URLEncoder;

/**

* A Simple REST client using Java HttpURLConnection class.

* @author rwatsh

public class RestClient {

/**

* @param args the command line arguments

public static void main(String[] args) throws IOException {

System.out.println(httpGet("http://localhost:8080/CustomerDB/webresources/entities.customer"));

}

public static String httpGet(String urlStr) throws IOException {

URL url = new URL(urlStr);

HttpURLConnection conn =

(HttpURLConnection) url.openConnection();

if (conn.getResponseCode() != 200) {

throw new IOException(conn.getResponseMessage());

}

// Buffer the result into a string

BufferedReader rd = new BufferedReader(

new InputStreamReader(conn.getInputStream()));

StringBuilder sb = new StringBuilder();

String line;

while ((line = rd.readLine()) != null) {

sb.append(line);

}

rd.close();

conn.disconnect();

return sb.toString();

}

public static String httpPost(String urlStr, String[] paramName,

String[] paramVal) throws Exception {

URL url = new URL(urlStr);

HttpURLConnection conn =

(HttpURLConnection) url.openConnection();

conn.setRequestMethod("POST");

conn.setDoOutput(true);

conn.setDoInput(true);

conn.setUseCaches(false);

conn.setAllowUserInteraction(false);

conn.setRequestProperty("Content-Type",

"application/x-www-form-urlencoded");

// Create the form content

OutputStream out = conn.getOutputStream();

Writer writer = new OutputStreamWriter(out, "UTF-8");

for (int i = 0; i < paramName.length; i++) {

writer.write(paramName[i]);

writer.write("=");

writer.write(URLEncoder.encode(paramVal[i], "UTF-8"));

writer.write("&");

}

writer.close();

out.close();