gomoob / oauth.js Goto Github PK

The library should definilty be published to npmjs.org, we should do it quickly because we are lucky, oauth.js is not reserved !

I implement a factory proxy which take an object like this

var bookService = {
    url: 'api/1.0/books',
    method: 'GET',
    params: {
        page: 1,
        line: 25 
    }
};

this factory doesn't use the shortcut method of $http service and take the object.

$http(bookService);

when I use oauth.js, the access_token didn't add because I have the console message followed from my API

code: 401
message: "The access token is missing"

Several updates have been applied to the StorageManager since the first release of the API.

The StorageManager source code is not clean, not well tested and documented, the following updates should be implemented :

• Remove deprecated methods
• Add shortcut methods to easier recurrent operations (get the access token, get the refresh token, get the date when the access token where retrieved, get the expiration time, get the expiration date, etc...)
• Move the code into a dedicated folder and create an abstract class AbstractStorageManager.
• The current StorageManager implementation should be an AbstractHtml5StorageManager and 2 other classes have to be created Html5LocalStorageStorageManager and Html5SessionStorageStorageManager

See http://www.w3.org/TR/IndexedDB.

We are trying to figure out how to use Oauth.js with Angular.
First question comes where to initialize the library via the init() method. We have guessed a good place would be on angular module configuration through a service.
The second question arises when we want to configure the Oauth object with the loginFn. We have no clue on how to create the modal from the service.
Could you please provide a full sample working with angular? I guess we are not making the right decisions and a simple full working sample would be most helpful.
Thanks in advance.

Implement a Storage Manager which stores informations inside Cookies.

In the _open function of the Angular Request Manager their is a console.log("reniew") which is associated to the case when an HTTP POST is done to send credentials and the server returns an error (an invalid_grant error for example).

This case has to be managed, also it seems some cases are missing with the parseErrorFn :

• When the server returns a response which corresponds to an action which should redirect to the login form the parseErrorFn should return a dedicated string to call the loginFn method subsequently
• When the server returns an expected API error OAuth.JS should simply notify Angular.

For now all the calls to secured requests have to be wrapped in OAuth.login. It works and it is very similar to the Facebook SDK but this perhaps not necessary.

Update the library to not beeing force to wrap everything in OAuth.login.

When a Request Manager starts it overwrites 3 methods of XMLHttpRequest 👍

• XMLHttpRequest#open(method, url, async, username, password)
• XMLHttpRequest#send(data)
• XMLHttpRequest#setRequestHeader(name, value)

The first time the XMLHttpRequest#open(method, url, async, username, password) is called it creates a RequestContext object which is stored inside a cache.

XMLHttpRequest.prototype.open = function() {

    // Creates a RequestContext object for the request
    var requestContext = OAuth.RequestContext.create(this, arguments);

    // Stores the RequestContext object in the RequestContext cache      
    This.addRequestContext(requestContext);

    // Calls the OAuth.JS overwritten 'open' method
    return This._open(requestContext);

};

The in the overwritten send and setRequestHeader methods we get the RequestObject back.

XMLHttpRequest.prototype.setRequestHeader = function(key, value) {

    // Gets the RequestContext associated to this original XMLHttpRequest object from the RequestContext cache 
    var requestContext = This.getRequestContext(this.getId());

    ...

};

For now the cache is managed directly in the AbstractRequestManager, to have something easy to test and update we should create a new dedicated RequestContextCache component.

Be careful in the implementation, the RequestContext objects associated to already used xhrs should be evicted to free memory.

For now we do not have any solution to use OAuth.JS with applications deployed in multiple domains.

Do do this implement a Storage Manager which uses the ZendDesk Cross Storage Storage Manager (https://github.com/zendesk/cross-storage).

Implement a React Request Manager.

When we do an OAuth.login(function(authStatus) { ... }); call the callback function has no mecanism to know if it was called directly or following a manual login.

In some cases the callback function has to do specific processing if the user was redirected to a login modal.

So it would be useful to have an authStatus.isFromManualLogin() function.

I bootstrap my app with object config like show in angular bootstrap

When I implement OAuth.init, I have the error

https://docs.angularjs.org/error/$injector/strictdi?p0=function($delegate

To fix them, I update the code like this

this._$provide.decorator(
                '$http', 
                ['$delegate', function($delegate) {
                       ...
                }]);

I didn't create a pull request for this issue.

With the multiple refactorings it seems the management of "reniew" is not working now.

The RequestContext object is used to transport all the xhrs, functions and parameters used to OAuth.JS to respond to an original developer or framework request.

This object is not already complete and should transport much more informations, here are the updates to apply to this object :

• Add a getOriginalXrhContext(), getReplacedXhrContext(), getRefreshXhrContext() and getReplayXhrContext() methods
• Add a setOriginalXhrContext(), setReplacedXhrContext(), setRefreshXhrContext() and setReplayXhrContext() methods.
• Add shortcut / utility methods isRefreshed(), isReplayed(), etc...

Then create an XhrContext component with the following methods and properties :

• getXhr() and setXhr()
• getOpenCallDescription() and setOpenCallDescription(args)
• getSendCallDescription() and setSendCallDescription(args)
• getSetRequestHeaderCallDescription() and setSetRequestHeaderCallDescription(args)
• setAccessToken(accessToken) and getAccessToken(), function used to get / set the OAuth 2.0 Access Token in the URL of the xhr object.

All those updates should allow some methods of the RequestManager like the _open method to be refactored to only take one requestContext argument as parameter.

For now OAuth.JS can create secured requests using a special secured parameter which can be provided with the options settings object of Backbone fetch methods and the config settings object of the Angular JS $http methods.

It works and it allows to have a very precise mechanism to choose when a request has to be secured and when it has'nt.

But in some cases this has several disavantages :

• When we want to integrate OAuth.JS into an existing application we have to modify all the call to the Framework's AJAX methods.
• On most applications all the calls have to be secured, so it would be more useful if the requests were secured by default.
• The calls to the Backbone fetch and Angular JS $http methods are done with an additional secured parameter which is not standard with those frameworks.

We thinks OAuth.JS could implement additional configuration to indicate how to secure the requests :

• Add URL prefix / regex configurations associated to names to indicate with which URLs the access_token parameter has to be added.
• Keep the secured and let it overwrite the URL prefix / regex configuration.

Here is a sample configuration with URL prefix / regex :

OAuth.init(
    {
        securedUrls : [
            usersApi : {
                prefix : 'http://website.org/rest/users'
            },
            groupsApi : {
                prefix : 'http://website.org/rest/groups/*/adminGroups'
            }
        ]
    }
);

The ResponseParser component and the ErrorResponse, CriticalErrorResponse and SuccessfulResponse implements several checks to ensure an OAuth 2.0 returns responses which are compliant with the OAuth 2.0 specifications.

However several Agmented Backus-Naur Form checks could be implemented additionnaly to ensure that each property of the JSON responses are valid.

An AbnfUtils component has been created with skeleton methods, we should implement all those methods and unit test them to be compliant with https://tools.ietf.org/html/rfc6749#appendix-A.

See http://www.w3.org/TR/webdatabase.

For now we have 2 separate request managers for Angular and Backbone. The Backbone implementation overwrites Backbone methods and uses jQuery, the Angular implementation overwrites the XMLHttpRequest objecft principally and uses function and object utilities embedded in the OAuth.JS library.

Update the code of request manager with the following modifications :

• Remove the use of jQuery mobile in the Backbone request manager
• Extract all the code which is common to Angular and Backbone to the AbstractRequestManager class
• Test the refactored Angular request manager
• Test the refactored Backbone request manager

Sometimes when we receive an error un the parseErrorFn we simply want to mark the AuthStatus as disconnected and redirect the user to a separate login page.

For now the parseErrorFn function has only one xhr argument, this is not powerful enough because it does not offer an access to other useful objects like the current requestContext.

Refactor the parseErrorFn function :

• Change the xhr argument with something which give access to more informations and functions.
• Implement something like requestContext.getAuthStatus().logoutAndRedirect('http://localhost/login');

Finally I'm wondering if the loginFn method is really useful as a developer could easily add a call to its login form directly in the parseErrorFn method and simply call the OAuth.sendCredentials() method again.