Thursday, October 12, 2017

JSON Viewer: JSONPath Expressions Evaluation


Added a new feature to JSON Viewer extension: evaluation of JSONPath expressions.



The source code: https://github.com/marss19/json-viewer-visual-studio-extension
The latest release in Visual Studio Marketplace: https://marketplace.visualstudio.com/items?itemName=MykolaTarasyuk.JSONViewer
 

Sunday, May 28, 2017

Reference Conflicts Analyzer - Visual Studio Extension

This is an extension to Visual Studio for easy visual analysis of the "Could not load file or assembly or one of its dependencies" problem and issues related to referenced assemblies. The tool allows selecting a .Net assembly (.dll or .exe file) and get a graph of all referenced assemblies with hightlighted conflicting references.

Source code: https://github.com/marss19/reference-conflicts-analyzer
Download: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Documentation

After installation, it is available in the main menu: Tools -> Analyze Assembly Dependencies.

Screenshot 1. Tool settings

Assembly to analyse: .Net DLL or EXE file which dependencies should be analysed.
Related config file: .exe.config for EXE file or web.config in case a web application DLL is selected. The extension inserts the related config automatically after the assembly is selected but it is also possible to select it manually.
Ignore system assemblies: by default the tool ignores assemblies which names start with "System..." to keep the graph clear.

Screenshot 2. Example of output


Thursday, March 2, 2017

Search for Movies and TV-series from the Chrome Context Menu

I noticed that sometimes, having a free evening and wishing to spend it watching a movie, I spent a lot of time selecting this movie, checking online movie databases for ratings, reviews, etc. As it was rather unproductive wasting of the time I created a simple Chrome extension helping to do the search easier and faster.

The extension adds context menu items executing search for a selected text (movie name).

There are also lots of sites which web masters overcomplicated them with scripts and CSS and made a simple selection of text quite a tricky thing. For these particular cases it is also possible to search without selection; for a focused text at cursor.

The extension is configurable: you can select preferable online movies databases.

Link:  https://chrome.google.com/webstore/detail/movies-tv-series-search/miploifkaagebhdlcdaaomgnenchiocf?hl=en&gl=PL

Preview:

Wednesday, April 27, 2016

Caching HTTP Handlers

There comes a time in an ASP.Net developer's life when he must write own HTTP handler. Quite often the handler has to return a static or a rarely changable content and the developer should implement caching of it.

Step 1. Specify how long data should retain cached.

Someone does it this way:

  context.Response.Cache.SetExpires(DateTime.Now.AddDay(1));

Someone likes this approach:

  context.Response.Cache.SetMaxAge(86400); //1 day in seconds

The most careful developers use both:

  context.Response.Cache.SetExpires(DateTime.Now.AddDay(1));
  context.Response.Cache.SetMaxAge(86400);

All the above are correct in their own way. The first example sets an absolute expiration date. In the list of headers it looks like this:

Expires: Mon, 25 Jul 2016 19:50:09 GMT
This header was introduced in the HTTP/1.0 specification but it is supported by HTTP/1.1 too. A small pitfall related to this header is that the expiration date and time are set explicitly and it may cause issues if time at an application server and proxy servers differ.

In order to fix the above issue a new header was introduced in HTTP/1.1: max-age. It specifies expiration time relatively to response time, i.e. an interval, in seconds, after elapsing it cached data are considered stale (expired).

Cache-Control: max-age=86400
In case both headers are set max-age has priority even if an Expires value is more restrictive.

At this stage many developers consider their work done and switch to other tasks. However...

Step 2. Define where to store cached content.

Let's run a HTTP trafic analyser, e.g. FireBug and look how our cached resource is loaded. Quite often we can notice that the resource is loaded again and again on each refresh with the 200(OK) status but without the (from cache) remark. Look at this header:

Cache-Control: private, max-age=86400
Private means that data can be cached by browsers only and cannot be cached at servers. Assuming that the browser cache is limited (e.g. the default size of the cache of Firefox is 50 MB) a browser you use may decide that letting a web site to occupy too much space is not the best idea and purge cached data. So if cached data are not "user sensitive" it makes sense to store them on servers.
context.Response.Cache.SetCacheability(HttpCacheability.Public);
More sophisticated options are described here: HttpCacheability Enumeration

At this stage even more developers conclude that their work done and switch to other tasks. However...

Step 3. Handle renewval of cached data.

Let's consider the following cases:

  • Proxy servers are overloaded and remove entries from the cache from time to time;
  • Cached entries are expired but still are not changed.
As a result the cached entries will be retrieved from the application server; this will increase traffic and reduce perfomance.

A proper approach is to avoid loading all data but just to return a response with 304 (Not changed) status. In order to do this set the Last Modified header:

context.Response.Cache.SetLastModified(new DateTime(2016, 4, 1));
which produces the output like this:
Last Modified: Fri Apr 1 2016 00:00:00 GMT
A server discovering that a cache entry is stale (expired) requests for a fresh copy of the entry and sends the If-Modified-Since header with the current date/time. We can handle this case and return a light-weight 304 response instead of sending the whole content.
var ifModifiedSinceHeader = context.Request.Headers["If-Modified-Since"];
if (!string.IsNullOrEmpty(ifModifiedSinceHeader))
{
    var ifModifiedSinceDate = DateTime.Parse(ifModifiedSinceHeader);
 
    if (/*cached data are not modified since this date*/)
    {
        context.Response.StatusCode = 304;
        context.Response.StatusDescription = "Not Modified";
        return;
    }
}
 
//otherwise return the normal response containing data and 
//do not forget about setting the Last Modified header...

Actually the above approach is basic one; it does not describe a lot of useful headers which can be used for tune adjustments of the caching process, e.g.: ETag, must-revalidate, etc.

Saturday, April 2, 2016

JIRA REST API: Cookie-based Authentication

Three authentication methods are proposed by the JIRA REST API documentation:
  • Basic Authentication is a simple but not very safe approach. Credentials are sent in the header on every request and encoding to Base64 is not a proper protection in this case; HTTPS connection is required.
  • OAuth authentication - looks a bit complex and requires additional configuration at the JIRA server that is not always possible.
  • Cookie-based Authentication - this approach seems to be the most convinient one: credentials are checked once, then the authentication cookie only is sent on subsequent requests.

However, trying to use the cookie-based authentication I encountered an issue. The approach described in the documentation worked partially: I was able to create a new session and get the response containing the session cookie but all subsequent requests using this session cookie were rejected as unauthorized. Spending some time investigating this I found the cause of the issue: JSESSIONID is not the only cookie which is required.

I am testing on a demo account which JIRA provides for trials on Atlassian Cloud. In my case for the proper authentication are also required:

  • atlassian.xsrf.token - Atlassian Cloud service's Server ID, a securely-generated random string (i.e. token) and a flag that indicates whether or not the user was logged in at the time the token was generated.
  • studio.crowd.tokenkey - authentication cookie which is used for single sign-on (SSO) between Atlassian Cloud applications. Like the JSESSIONID cookie, this cookie also contains a random string and the cookie expires at the end of every session or when the browser is closed.
More details on JIRA API cookies used by Atlassian Cloud are here: https://confluence.atlassian.com/cloud/cookies-744721661.html. I suppose in case of internal hosting of the JIRA server the cookies set may differ so a safe approach seems to be to re-send all cookies the method got during creation of the session.

Below is the example of usage of the cookie-based authentication to retrieve data from JIRA API.

    var baseUrl = //URL to your JIRA server, e.g.  https://<YOUR ACCOUNT>.atlassian.net
    var userName = ...
    var password = ...

    var dataProvider = new JiraApi();
    IDictionary<string, string> cookies;
    if (dataProvider.TryLogin(baseUrl, userName, password, out cookies))
    {
         //just for example: retrieves all issues of the specified type
         dataProvider.SearchForIssues(baseUrl, cookies, "type=Story"); 
         dataProvider.Logout(baseUrl, cookies);
    }

Actually the logout is not a required step; the cookies can be saved somewhere and used until they expired (30 days).

I used RestSharp to keep the below code simple, however the approach should also work with the plain HttpWebRequest. Also for simplicity of the example I used client.Execute instead of more convinient client.Execute<T> which allows to deserialize the response content from JSON to entities.

    
    public class JiraApi
    {
        public bool TryLogin(string baseUrl, string userName, string password, 
              out IDictionary<string, string> cookies)
        {
            var client = new RestClient(baseUrl);

            var request = new RestRequest("/rest/auth/1/session", Method.POST);
            request.RequestFormat = DataFormat.Json;
            request.AddBody(new { username = userName, password = password });

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.OK)
            {
                cookies = response.Cookies.ToDictionary(x => x.Name, x => x.Value);
                return true;
            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...

                cookies = null;
                return false;
            }
        }

        public void SearchForIssues(string baseUrl, IDictionary<string, string> cookies, string jql)
        {
            var client = new RestClient(baseUrl);
            var request = new RestRequest("/rest/api/2/search", Method.GET);
            request.RequestFormat = DataFormat.Json;
            request.AddBody(new { jql = jql });

            foreach (var cookie in cookies)
                request.AddCookie(cookie.Key, cookie.Value);

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.OK)
            {
                var content = response.Content;

                //handle results here
                //...

            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...
            }
        }

        public void Logout(string baseUrl, IDictionary<string, string> cookies)
        {
            var client = new RestClient(baseUrl);
            var request = new RestRequest("/rest/auth/1/session", Method.DELETE);
            foreach (var cookie in cookies)
                request.AddCookie(cookie.Key, cookie.Value);

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.NoContent)
            {
                //handle results here
                //...

            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...
            }
        }

Note that the successful deletion of the session returns NoContent status code instead of OK.