Tech Notes

Friday 14 August 2015

OAuth2 - Why Authorization Code Grant Type exist at all?

If you have worked with or read about OAuth 2, you would have came across the fact that it has several "Grant Types".

The two of interest to me was:

Authorization Code
Implicit

When I was reading up on this topic, I couldn't understand why the Authorization Code grant type was necessary at all.

A quick recap the 2 grant types:

Authorization Code

Resource Owner (User) is prompted by the Resource Server (e.g. Facebook), asking

"XXX App wants to use your profile ..blah blah, do you allow it to do so??"

User confirms. Resource Server redirects to the registered redirection link along with an "auth-code" in the param:

https://oauth2client.com/cb?code=AUTH_CODE_HERE

The client then needs to make an extra POST request to the Resource Server with the auth-code, clientId and the clientSecret to get the Access_Token.

The access token is the thing you attach to your subsequent requests to access the user resource.

Implicit

Up to a point, it is the same as Authorization Code described above. However, instead of sending back an "auth-code", the resource server will immediately send back the access-token! No extra step required! The auth token is sent back as a hash fragment, NOT a request parameter (this point is important).

https://oauth2client.com/cb#token=ACCESS_TOKEN

Question

Both grant-type results in the ACCESS_TOKEN being sent back to the client after the Resource Owner agrees to share his resource. So why do we need the authorization code grant type that has an extra step??

Answer

Hash Fragment is a browser thing. It is not part of an http request, and when your request url looks like https://oauth2client.com/cb#token=ACCESS_TOKEN The #token=ACCESS_TOKEN is not sent to the server.

This means it can't be read or intercepted by any servers (duh...its not sent!), so its secure without TLS. I.e. its secured from Man in the Middle Attack.

However, it also means that this only works if the request is sent from the browser. Good for your SPAs (Single Page Apps) and mobile apps.

We need to do something Web Servers and other non browser systems that requests for resource as well.

Since they Hash Fragments aren't sent to the server, information will have to be passed in the form of url parameters, but (unless the client is using TLS which is not a requirement for a OAuth2 redirect url) any server can read URL parameter, its part of the HTTP request which means its susceptible to a man in the middle attack. So we cannot just attach the access token to it.

So instead, the Resource Server sends back a redirect with an auth_code in it.

The idea behind the auth code is that ONLY a legitimate client (i.e. the one that holds the client secret .. kinda like a private key) will be able to exchange the code for a token.

To exchange the auth code, the client has to issue a POST request to the Resource Server. The POST request has to include the auth_code, the clientId AND the clientSecret, and the response to this will be the ACCESS_TOKEN.

At this point you might be asking (... at least I was), why can the Resource Server send back an Access Token after the POST? Why couldn't it just do that in the first request when it sent back the Auth_code??

The key here is that first was a redirect to client's page. The client may or may not be HTTPS which means the response maybe in clear text! The second was a request and response to the Resource Server which MUST be in HTTPS (which is why you can safely send your Client Secret and get the Access Token).

References:

https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified

http://stackoverflow.com/questions/13387698/why-is-there-an-authorization-code-flow-in-oauth2-when-implicit-flow-works-s

Monday 7 April 2014

Hibernate: Beware of OneToOne Mappings

Problem Background

So recently I had to deal with a performance issue at my job. Its a simple JSP page, and it returns maybe a 1000 or so record.

Simple. Or so I thought. I can write a select query in SQL and return all the data it needs that will take almost no time to run.

So why is it that my application (backed by Hibernate) takes 10sec to load this page?

After a bit of digging and profiling we found the culprit. It was a query written in HQL that seems to do more or less exactly what my SQL query was doing. However, what it was also doing was about 4 or 5 extra follow up queries for EVERY SINGLE result that was returned in the first query.
This is a well known problem in the hibernate world, its known as the "N+1 Select" problem.

So what causes this problem and how to work around it?

Cause : OneToOne Mapping

OneToOne mapping are dangerous if you don't know what hibernate is doing in the background.
Lazy fetching does NOT work with entities which are mapped as OneToOne when the relationship is optional.

I.e. the following will NOT be using lazy fetch:
@OneToOne(fetch = FetchType.LAZY, optional = true)
@OneToOne(fetch = FetchType.LAZY) //default optional is true.

So if you have an HQL, that brings back an Entity that has a optional OneToOne mapping to another entity, after executing the original HQL it will issue a separate query for every single result returned in your query for every single optional OneToOne entity that your result references.

Example:
class A {
@OneToOne(fetch = FetchType.LAZY)
B b;

@OneToOne(fetch = FetchType.LAZY)
C c;

@OneToOne(fetch = FetchType.LAZY)
D d;
}

If I have class A above and I write a query that brings back 1000 A entity, it will issue 1000 separate queries to fetch B, 1000 queries to fetch C, 1000 queries to fetch D. That's 3001 queries all together, instead of just the 1!

Why?
When your OneToOne mapping is optional i.e. (the relationship is really 1 : 0/1), how does hibernate know whether to return null or a proxy object when you try to access this entity? Hibernate must issue select query to the database to see if the object exists, and if it has to issue a query, it might as well just return the object, so the object is always fetched.

Tip No.1: If you OneToOne mapping is NOT optional set optional = false.

This will hint to hibernate that this object will always exist, and if I am lazily fetching this, you can just create a proxy for it.

Optional OneToOne

As mentioned above, hibernate needs to issue a query to figure out whether an child entity is null when you have a OneToOne mapping which is optional effectively preventing lazy loading. So what if my OneToOne mapping REALLY is optional, am I stuck with this N+1 problem?

Option 1 : Fake One To Many

One way to work around it is to use a "fake OneToMany" mapping instead.
This is a pretty simple trick, instead of using OneToOne, you use OneToMany, and you change the field type to a Set.

Hibernate has no problem lazy loading collection because a collection is never null, the collection can be empty or it can have some data in it, but the collection is never null.

To prevent breaking your existing code, you must now also change the IMPLEMENTATION of you GETTERS and SETTERS.

For example:

public YourType getA(){
return this.a;
}

public void setA(YourType a){
this.a = a;
}

change it to:

public YourType getA(){
if (a.isEmpty()){
return null; //This will ensure the code behave the same as before.
}
return this.a.iterator().next(); //Remember "a" is now a Set
}

public void setA(YourType a){
this.a.clear();
this.a.add(a);
}

The above changes should ensure that your exist code does not break (unless you are doing direct field access, or reflection stuff.. then all bets are off!)

Option 2 : Use JOIN FETCH in your query

Another option (if you problem is specifically related to specific HQL query which you are trying to tune), is to perform a JOIN FETCH on those OneToOne entities.

Your HQL query might look something like this:
" FROM com.example.A AS A "

change it to:

" FROM com.example.A AS A "
+ "LEFT JOIN FETCH A.b AS B "
+ "LEFT JOIN FETCH A.c AS C "
+ "LEFT JOIN FETCH A.d AS D "

The above changes should prevent it from issuing further queries to fetch the Bs, Cs, and Ds, it will fetch all the information it needs in one query.

Problem with Subclass and Instanceof

So we were implementing the changes recommended above, and one of the problem that we hit is when you specify a non-optional OneToOne mapping to an abstract super class.

Prior to telling hibernate that the OneToOne mapping is non-optional, hibernate issues query to bring back the actual object and in doing so it will always return the concrete sub class (hibernate figures out the correct sub class by doing a left outer join to all sub class tables). However, once I added the "optional = false" argument to the mapping annotation, hibernate started creating proxy for the super class (which is correct because its now correctly lazy loading your OneToOne mapping!), but its a problem if you are using the instanceof operator on the proxy field!

Example:

abstract class Drink {}

class Coke extends Drink{}

class Milk extends Drink{}

class Fridge{
@JoinColumn(name = "drinkId", nullable = false)
@OneToOne(fetch = FetchType.LAZY, optional = false)
Drink drink;

Drink getDrink(){
}
}

When I have code like the following:

Fridge fridge = .... //some code that gives me my fridge.
if (fridge.getDrink() instanceof Milk){
// you got milk!
} else {
// you got coke!
}

This code would fail, where it wouldn't before! Before the change fridge.getDrink() would return either a Coke or Milk, because its actually returning the actual object in the database. After the change, fridge.getDrink() actually returns an javaassist proxy to Drink!

If you step through the code in the debugger, you will see that fridge.getDrink() is actually returning something like com.example.Drink_$$_javassist_1, its neither a Milk or Coke! Its hibernate generated proxy class, which means your instanceof check will fail! If you try to cast it to a Milk or Coke, you will get a ClassCastException!

So after a bit of googling the way we found to overcome this problem is to write a util method which will convert a hibernate proxy object to the actual implementation.

public static T initializeAndUnproxy(final T entity) {
if (entity == null) {
return null;
}

Hibernate.initialize(entity);
if (entity instanceof HibernateProxy) {
return (T) ((HibernateProxy) entity).getHibernateLazyInitializer().getImplementation();
} else {
return entity;
}
}

With this method you can do the following:

Fridge fridge = .... //some code that gives me my fridge.
Drink drink = initializeAndUnproxy(fridge.getDrink());

if (drink instanceof Milk){
// you got milk!
} else {
// you got coke!
}

Saturday 4 January 2014

JSONP in a nutshell

JSONP In a Nutshell

is basically a way invented to get around the Single Origin Policy, thus allowing the user access to resources that that comes from another domain.

It came about BEFORE the introduction of CORS, which is the proper non hacky way of accessing cross origin resources. (This is a guess .. I don't see why JSONP will be needed if CORS existed before it.)

How does it work?
Assuming I run a website (www.mysite.com) and I want to access a RESTFul resource on another site (www.othersite.com/user/1234) which returns some JSON:

{
userId : 1234,
userName : 'Jeff'
}

Without using CORS, there are actually no way for me to do this.

So some clever people figured out that since script tags are exempt by the brower from Single Origin Policy. They can use a script tag like this to load the resource:

<script src="www.othersite.com/user/1234" type="application/javascrpt" ></script>

to try and load the resource.
However this doesn't work. The script just gets evaluated, but you cant actually do anything with the resource, and this is where JSONP comes in.

By telling the server, to wrap the response in a javascript function that YOU want it to call when the script is evaluated, you now effectively can access the cross origin resource!

For example:

<script src="www.othersite.com/user/1234?callback=executeMe" type="application/javascrpt" > </script>

The server can be configured to return the following when it sees the callback request param:

executeMe({
userId : 1234,
userName : 'Jeff'
});

and when this is sent to the browser, it will be evaluated and your executeMe function will be executed with the cross origin data that you requested for!

* executeMe will be a function that's already defined on your page.

Summary

Its pretty much a hack to work around Same Origin Policy. Should just use CORS now...
The server side needs to implement this. I.e. its NOT like I can use JSONP to access any resource on the web I want. (Its NOT a hacking tool ..)
If you are using JSONP to serve up some data, then your server is vulnerable, because anyone now can access that resource (unless you protect it some other way ..)

Tuesday 3 December 2013

Database Isolation Levels In Layman Terms

In my career, I have had to deal with database isolation levels on a handful of occasions.

I can never remember them on top of my head, and had always resort to googling, which is fine.. but most of the time I just want to know in a sentence or two what are the isolation levels and how are they different to each other.

So here it is (in increasing level of isolation and slowness..):

READ UNCOMMITTED
This means the data you read may not have been committed. I.e. a transaction may have done an update or insert, but it hasn't actually committed it. I.e. you may have a "Dirty Read"

READ COMMITTED
Guarantees data read has been committed at the moment it is read. Prevents "Dirty Read".

This has 2 options in MSSQL - snapshot on/off
On - Puts a version number on the rows you are reading, so effectively every transaction sees a SNAPSHOT of the data at the time of read.

Off - Locks the rows you are reading from being edited by another transaction.

REPEATABLE READ
In addition to Read Committed, it also guarantees that any data already read CANNOT change, even in the same transaction. I.e. with in a transaction you can read the data any time, and you are guaranteed you that the rows you read before is UNCHANGED (but you may see MORE rows added)

SERIALIZABLE
In addition to READ COMMITTED and REPEATABLE READ, it also guarantees NO NEW data can be seen by a subsequent read. I.e. once you did a select * on a table, no concurrent transaction can UPDATE/INSERT/DELETE on that table!

A very good example I pulled from Stack Overflow:

BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;

under READ COMITTED, the second SELECT may return any data. A concurrent transaction may update the record, delete it, insert new records. The second select will always see the new data.
under REPEATABLE READ the second SELECT is guaranteed to see the rows that has seen at first select unchanged. New rows may be added by a concurrent transaction in that one minute, but the existing rows cannot be deleted nor changed.
under SERIALIZABLE reads the second select is guaranteed to see exactly the same rows as the first. No row can change, nor deleted, nor new rows could be inserted by a concurrent transaction.

Wednesday 20 November 2013

JavaScript Basics

I recently gave a short prezi presentation about some basic javascript concepts that everyone claiming to know javascript should know!

Enjoy!

Click Me for the Presentation

Friday 25 October 2013

My own implementation of MergeSort

Took me an hour to nut out ... but I did it by myself without looking at the wikipedia's implementation!

Probably not the best way to implement it ... but I don't care at the moment, just feel happy that I did it :-)

 <html>

Monday 7 October 2013

proto vs .prototype

What is __proto__?

Every object in javascript has a __proto__ property.

The __proto__ property points to object that this object inherits from.

By default an object non-function points to Object.prototype.
(Object.prototype is basically the root object, and its __proto__ is null) i.e. (Object.prototype.__proto__) is null.

By default an function object points to Function.prototype (Function.prototype this is where function inherits methods like .apply(), .call(), etc...)
Function.prototype__proto__ points to Object.prototype.

Invoking a function as a constructor
This basically just means calling a function using the keyword new.

When you do that the __proto__ of object created becomes the functions ".prototype" which by default which will be Object.prototype.

NOTE this is not the same as the function object's __proto__ which is Function.prototype.

I.e. by default:
var y = function(){}

y.__proto__ = Function.prototype
y.prototype = Object.prototype

What is .prototype?
By setting .prototype on a function object which is going to be invoked as a constructor, we are basically setting the __proto__ property for the object that is goingto be created using this function.

To Summarize

var x = {};
// x.__proto__ = Object.prototype

var f = function(){};
// f.__proto__ = Function.prototype
// f.prototype = Object.prototype

f.prototype = x;
// f.__proto__ = Function.prototype
// f.prototype = x (duh!)

var y = new f();
// y.__proto__ = x;