Author at Infinum

Overcome Token Storage and Security Challenges of OAuth2

Darko Kukovec — Thu, 13 Jul 2023 13:29:15 +0000

Saving tokens securely when using OAuth2 is often mishandled, even in tutorials, so we decided to implement the recommendations from the official specification by ourselves. Let us introduce you to our new open-source library – auth-worker.

OAuth2 is a protocol widely used in modern web and mobile applications, enabling seamless integration with third-party services. You must have seen web pages or apps that have a “login with Google/Facebook/Twitter/other service” option – this functionality is built upon the OAuth2 standard.

However, secure token storage with OAuth2 can be a challenge, and all of the tutorials available seem to mishandle the issue.

With OAuth2 specification as the basis, we implemented the official recommendations and created an open-source library that enables secure token storage.

In this blog post, we present both the security problem and the solution, focusing on the implementation of OAuth2 in the browser, and more specifically, in single-page applications.

What is OAuth2?

OAuth2 is an open standard protocol that provides a secure and standardized way for users to grant limited access to their protected resources on one website (the resource server) to another website or application (the client) without having to share their login credentials. It acts as an authorization framework, allowing users to delegate access rights to their resources across websites and applications.

Why use OAuth2?

There are many benefits to using OAuth2. First and foremost, it enhances security by eliminating the need for users to share their usernames and passwords with third-party applications. Instead, OAuth2 relies on authorization tokens, reducing the risk of credential theft and unauthorized access.

This framework also offers fine-grained control over access permissions, allowing users to grant specific rights to different applications. It provides a layer of abstraction, ensuring that users retain control over their data with the option to revoke access at any time.

OAuth2 promotes interoperability and simplifies integration between different platforms, fostering the development of a vibrant ecosystem of interconnected services.

Furter, OAuth2 enhances user experience by enabling the single sign-on (SSO) functionality. Users can authenticate once with the identity provider (such as Google or Facebook) and then seamlessly access multiple applications and services without the need to log in repeatedly. This streamlines the login process, reduces friction, and improves usability across various platforms and devices.

OAuth2 also encourages innovation and collaboration by facilitating the integration of third-party services, allowing developers to leverage existing platforms and extend the functionality of their applications without reinventing the wheel.

What the tutorials get wrong

If you search for tutorials on how to implement OAuth2 in a JavaScript application, almost every tutorial or article will make one crucial mistake – how to save tokens.

The most obvious way to save data in the browser is to simply save it to localStorage. If you are trying to be more conscious of security, you might decide that sessionStorage is better, or perhaps cookies. However, out of those options, only one is secure enough to store credentials, and only under specific circumstances – http-only cookies

With http-only cookies, the server sets the cookie, and only the server can read it – it is completely invisible to the JS app in the browser. However, this might not always be an option as OAuth2 providers usually don’t support this method.

The problem with localStorage, sessionStorage, and regular cookies (or any other similar storage, like IndexedDB) is that they can be accessed by the JS code and are therefore susceptible to XSS attacks.

There are multiple real scenarios when this could become an issue:

A compromised dependency could add some code that steals the tokens
Some user input might not be escaped well enough, and a malicious user could insert code that would steal the tokens
If you’re using tools like Google Tag Manager, someone could unknowingly (e.g., while not checking it closely enough) inject a malicious script through the GTM dashboard that steals the tokens
A rogue browser extension installed in the user’s browser that is stealing data from browser storage and sending it to its owner

Of course, in some cases, the risk might be acceptable – if it’s just an internal app and all other best practices are followed, and the expiration time of the tokens is short, these security risks might not matter to you. Regardless, this should be an educated decision with known risks.

So, what is the solution?

Surprisingly, despite many tutorials mishandling this issue, the OAuth2 specification actually has some good recommendations on how to solve this issue.

Apps with server-side rendering

In many cases, when we’re using React, we also use Next.js, which basically gives us a lot of flexibility. In this case, the simplest solution is to use the Backend for Frontend Proxy with http-only cookies by using the Next.js API endpoints as a proxy for all authenticated API calls. We also combine this with NextAuth.js, which handles the login and token exchange in a secure way (on the server side).

Client-side rendered apps

If you don’t have a dedicated server, things are a bit trickier. To handle tokens in a secure way (and not expose them in the browser scope), the specification suggests leveraging Service Worker.

The OAuth2 specification recommends using Service Workers because they can intercept API calls and add the credentials before passing the API call to the server. They can also intercept the login flow – that way, no sensitive data needs to be exposed to the main browser thread.

SOURCE: IETF

In this case, one big downside of client-side rendered apps is that there is no secure way to persist the tokens in the browser because all storage options are available across all scopes. This means that the tokens exist only in the service worker’s memory. Since Service Workers usually have a longer lifespan than the web pages they belong to, the UX will not be significantly compromised. In some cases, an acceptable compromise would be to encrypt the data with a key that is hardcoded in the service worker, but this is more of a security through obscurity solution, and it’s not covered in the best practices document.

And it’s not just the tutorials…

If we look at the OAuth2 libraries and SDKs from some big names like Auth0 and Microsoft, we can see that they make the same mistake – asking the user to detect a callback and then saving the data into the regular cookie or local/session storage. This leads us to wonder why they would not implement the best practice that some of them (e.g., Okta, the owner of Auth0) contributed to. It is possible that this is due to issues with Service Workers:

Developer Experience while using SW is worse than without them – it is harder to revalidate things, the DevTools are not that polished, etc.
Browser support – until recently, Service Workers were not a viable solution for general usage. Right now, however, all major browsers (except Firefox in Private Mode) support Service Workers.

OAuth2 implementation security issue – solved

Since there seemed to be no good solution for this problem (at least not one that is provider-agnostic), we decided to make our own – and open-source it.

Meet auth-worker, a library that does most of the heavy lifting of Oauth2 authentication with the workers. It has built-in support for some OAuth2 providers (e.g., Google and Facebook), and anyone can define their custom providers, with new ones to be added in the future.

Auth-worker also manages the PKCE flow and OAuth2 state (both of these are security recommendations from the specification) automatically without any extra work from the app side.

If it is an acceptable compromise for you, the library also supports persisting the encrypted auth data in IndexedDB.

To get started with the library, you just need to do three things:

Create a service worker:

// service-worker.ts
import { initAuthServiceWorker } from 'auth-worker/worker';
import { google } from 'auth-worker/providers';
initAuthServiceWorker({ google }, '/auth', ['/allowed', '/routes']);

Load the service worker:

// index.ts
import { loadAuthServiceWorker } from 'auth-worker';
loadAuthServiceWorker({
      google: {
             clientId: 'example-client-id',
             scopes: 'https://www.googleapis.com/auth/userinfo.profile',
      },
}).catch(console.error);

Start using the library.

Here is an example of how to make an authenticated API call:

const response = await fetch('https://example.com/api', {
      method: 'POST',
      headers: {
             'Content-Type': 'application/json',
             'X-Use-Auth': 'true', // This is how we tell the library that we want auth
      },
      body: JSON.stringify({
            foo: 'bar',
      }),
});

Prioritize security with auth-worker

There are a lot of different ways to implement authentication, but all of them have their pros and cons. Depending on your requirements, you might choose a different approach, but it is always important to keep security in mind and make decisions that don’t endanger the safety of users or our data. We hope that you find auth-worker useful in overcoming the token storage and security challenges of OAuth2.

The post Overcome Token Storage and Security Challenges of OAuth2 appeared first on Infinum.

AI Coding Assistants – Developers’ Friends or Foes?

Darko Kukovec — Mon, 13 Mar 2023 13:41:05 +0000

Although it may seem counterintuitive, AI tools can be of greatest help to those who already know what they’re doing.

Three engineers walk into a bar. Together, they have 25 years of experience, but 15 of those belong to one of them. How many years of experience do the other two engineers have?

This seems like a typical question people are asking ChatGPT these days. After all, outsmarting AI is the ultimate goal – or is it?

We asked three flesh-and-blood engineers about their experience of working with AI coding assistants GitHub Copilot and ChatGPT, and found out whether they recommend using them – and in what cases.

These are their stories. *tn tn*

The flesh-and-blood engineers who participated in this experiment

Marin Teskera, a junior developer fresh off of JavaScript course at Infinum Academy. He is at the beginning of his career and eager to learn the intricacies of programming.

Tomislav Habalija, a JavaScript engineer turned JavaScript team lead, who also wrote the Angular course curriculum for Infinum Academy and mentored Marin at the JavaScript course. He’s been in the biz for seven years.

Darko Kukovec, an experienced JavaScript and TypeScript engineer with +15 years of code writing under his belt. He is the head of frontend development.

As the pressure to implement AI grows, many businesses don’t know where to start. Our 14-day sprint helps you cut through the noise—turning early ideas into validated prototypes with clear logic, smart design, and real momentum. Learn how it works.

Where did AI code writing assistants prove to be useful?

Using a coding assistant for writing boilerplate code

Nobody likes it, but boilerplate is always there. It’s a hassle to read and maintain it, so any kind of a helping hand is a godsend. Whether it’s lists of data or some repetitive code, types, or just long names of variables and functions, it’s easier to use an AI coding assistant to write it, and then check if everything is ok than to do the whole thing from scratch.

Also, as our Marin puts it, “doesn’t it feel great when the AI coding assistant recommends something you were going to write anyway?” #sanityCheck

Using a coding assistant for writing documentation

Sometimes you know exactly what you want to do, but you can’t fully remember the documentation for some API (e.g. DOM, or even your own code). The copilot might be able to autocomplete big chunks of the code without having to switch tabs or apps to check the docs.

What tasks did AI code writing assistants struggle with?

Using AI tools for learning something new

With a lot of JavaScript tooling being written in Rust nowadays, Darko Kukovac decided to try out first-hand what all the fuss was about. He opted for Rust when solving the 2022 edition of advent of code.

“In preparation, I had just enough time to read the first six chapters of the Rust docs – not great, not terrible. This was enough to get familiar with the basic concepts, but without any practical knowledge, it would surely be quite annoying to google solutions for each trivial issue I encountered. After all, that’s what happened when I tried Kotlin a few years ago,” Darko said.

Copilot did its job and got Darko through the first few days with much less frustration than expected. Of course, he still had to google things, but mostly on the conceptual level and not syntax or trivial issues. After a few days, he noticed his understanding of the language got better, and he was able to better understand Copilot’s suggestions and assess if they were good solutions or not.

Looking back at the code that Darko wrote himself and the code where he trusted Copilot (almost) blindly, he concludes:

“The Copilot code is somewhat weaker because it adds extra steps or does some things in a less-than-ideal way. However, I do believe it can help engineers kickstart their learning experience, which is a plus.”

Using code you don’t understand

What happens when the AI helper recommends code you don’t understand?

By just mindlessly pressing the tab key, developers who are still learning the ropes can miss the opportunity to learn by trial and error.

For example, in last year’s edition of Infinum Academy, our mentor Tomislav Habalija had a few students who were writing suspiciously clean code:

“I had a hunch something was going on until I realized they were using GitHub Copilot.”

It is a tool, or as they say on their website – AI pair programmer, which speeds up your developing process by giving you suggestions on what to write next.

For example, let’s say you want to write a simple function that calculates average numbers. Just by writing the function calculateAverage and selecting the first GitHub Copilot example, you will get the correct implementation.

function calculateAverage(numbers) {
  const sum = numbers.reduce((acc, number) => acc + number, 0);
  return sum / numbers.length;
}

This can be a great time saver for a senior developer who knows what they are doing but a big pitfall for junior developers. “By writing code from scratch, you are learning, and while using tools like this, you are just writing code,” says Tomislav.

Introducing bugs while you introduce “correct” code

If you’re not that experienced, blindly trusting the coding assistant can result in using code that is plain wrong.

But even if the code is correct and it works, it doesn’t always follow best practices. It might also introduce errors that a beginner doesn’t know how to fix. That is really not ideal when working on a bigger project because when another programmer starts to work on the code, they may have a hard time following it.

Case in point: Tomislav Habalija tested this when he was writing a regular expression:

“I had to write a regex for removing query params from the string. Easy enough, right? So I asked the AI.”

This was Tomislav’s prompt:

Write a regex for removing query params from the string using javascript.

And he received a correct response:

const removeQueryParams = (url) => url.replace(/\?.*/, '');

This solved one case but added a bug to the rest of the code because the team was using templated links. ChatGPT couldn’t know that, as Tomislav did not mention it.

Back to the drawing board, Tomislav tried another prompt:

Write a regex for removing query params from the url that contains templated strings. Templated part starts with { and ends with }. Templated part must not be removed from the string.

This time, the answer was slightly better.

const removeQueryParams = (url) => url.replace(/\?(?:[^{]*&)?([^#]*)#?.*/, '$1');

“Regex is bigger, it should be correct, right? Right? I have tried it out in my code, and I was surprised when the tests started failing. The answer was still wrong,” Tomislav decided before giving AI one final chance.

The provided answer still removes the templated part. For example, regex should not remove “{?foo}” or “{?bar}” from “http://www.test.com{?foo}/bar{?bar}?first_param=1&second=2”. Can you try again?

AI’s response was “Here is a modified regular expression that will remove the query parameters from a URL string, while leaving any templated parts of the URL intact:”

url.replace(/\?(?:[^?{]*&)?([^#]*)(#?.*)/, '$1$2');

This answer was even worse than the one before. The answer Tomislav was looking for was:

url.replace(/([^{])\?[^/]+/, '$1');

And he couldn’t get AI to come up with that. At least not with the questions and descriptions he provided.

Privacy considerations

Since both GitHub Copilot and ChatGPT use their servers to generate results, the question is what happens with the data entered. How is it used? This might be a very important question if you’re working on a project that is not open source.

In the case of Copilot, there’s an option in settings that allows it to use your code to train the AI – this doesn’t mean that someone will get your snippet of code, but someone might get a code snippet that was in part inspired by your code. If you’re working on code that is not open source or the license doesn’t allow this type of usage, you should disable this option.

On the other hand, ChatGPT doesn’t have such settings, and all entered data could be used to train the AI. That’s why you should always be careful what you enter into the system and obfuscate any information you don’t want to share with anyone.

Turns out, AI coding assistants are only as smart as the engineer using them

Our engineers all agreed that using an AI coding assistant makes the most sense for more experienced developers who know what they are doing.

For people trying to learn, like our junior engineer Marin, using a tool like this brings the same benefits as for the experienced developer. However, they should be careful about using code they don’t understand because it can affect their learning curve, or they might even end up introducing the wrong functionalities.

Using AI coding assistants with a grain of salt can speed up development, but for now at least, it is not ready to take over the wheel.

If you are interested in utilizing AI in your digital product, see how we can help you on the way.

The post AI Coding Assistants – Developers’ Friends or Foes? appeared first on Infinum.

The Role of JavaScript in the Biggest Apple Security Breach

Darko Kukovec — Tue, 03 Sep 2019 15:05:00 +0000

A few months ago, Google Project Zero discovered a bunch of security exploits in iOS versions from 10.0 up to 12.1.3 that cover a total of 1.4 billion devices.

Last week, they published their findings in more detail. What part did JavaScript play in the incident?

What’s the issue with Safari?

Based on the Google Project Zero research, a malicious website would be able to install a monitoring implant on the phone, and the implant would have access to pretty much everything on the phone–photos, contacts, messages, the real-time location, and keychain (passwords, certificates, etc.)

Based on Google’s investigation, this was used by the Chinese government to target some of their citizens. They estimate a few thousands of people a day were targeted for up to 2 years, but it’s hard to know if they were the only ones.

We’re talking more than 2 million instances of privacy breaches, and that’s just the part that’s been accounted for.

Why is this relevant for developers?

Perhaps not directly, but any developer using iOS, or any “smart” device for that matter (yes, even a blender), should make sure they are up-to-date with the latest security updates. To me, the most interesting part of this privacy breach was how the attackers found the security issues.

The issues are mostly using array or object bugs to gain read/write access to the system memory and then use some lower level OS issues to install the tracker.

The most likely scenario is that the attackers used the open source nature of WebKit and to find the vulnerabilities affecting the Safari browser on iOS. Once a vulnerability was detected by someone and reported to Apple, it would usually be fixed, test cases (both JavaScript and C++) were added and a nice descriptive commit message was written.

The problem here is that with WebKit being open source, and the fact it is updated together with the OS, the fix would be waiting for the next OS release–usually for months. All the while, the vulnerability was exposed to the public.

Keeping your business safe starts with penetration testing—simulated attacks that assess your security posture. Explore our pentesting services and discover any vulnerabilities in your system before malicious actors do.

Is there a problem with other platforms?

Chrome and the new Edge

The same issue could happen, but a bit more unlikely because the release cycle is faster, and they generally don’t include JavaScript test cases. Therefore, the attackers would need to reverse-engineer the commit instead of just copy/pasting the problematic code.

Firefox and the old Edge

Mozilla and Microsoft keep the security commits private until the release is public, so the chances of this are very slim.

Other open source projects

The majority of other projects, like Linux and Android have a similar approach to Mozilla, in which they discuss and prepare security fixes in private, and publish them publicly only after they’re ready to be installed on the affected systems.

Safety measures you should be taking

In the case described above, it seems like malicious websites added the problematic code themselves, but it could have also been added by some third party.

Although it’s not realistic to review all the source code of all the dependencies we’re using, it’s important to use reliable libraries from well-known authors (which is also not a 100% guarantee) whenever possible.

Also, keep an eye on the npm install command, which is doing an automated security audit of all installed packages, and run npm audit / yarn audit manually from time to time–or use the GitHub’s security monitoring feature.

Better safe than sorry!

In case you’d like to consult on improving your company’s security posture, check out our cybersecurity services.

The post The Role of JavaScript in the Biggest Apple Security Breach appeared first on Infinum.

Squeezing Webpack into Backend Frameworks

Darko Kukovec — Tue, 24 Jan 2017 10:46:00 +0000

If you ever made a website, it probably contained some assets like images, CSS and JavaScript. In order for a page to be fast, it’s a good idea to concatenate all your JavaScript assets into one file and all your CSS assets into another. Caching might also be tricky…

Working with assets 101

If you want to concatenate files, use SASS or make sure your files are not cached when they shouldn’t be, you’ll need to use a tool that will take care of that. Most web frameworks have tools that work out of the box, but that might not be good enough for everyone.

The asset pipeline

The asset pipeline is Rails’ way of preparing files for production. Other frameworks might use different names for it, but they all mostly do the same thing.

The basic Ruby on Rails request flow

Module bundlers

A module bundler does a similar thing, but it is generally more flexible. The final product (files) might be similar, but it does more things in between.

Webpack – the good parts

Webpack is a module bundler that is getting more popular day by day. Although this is mostly because of the React community, it gained a lot traction in other communities, e.g. the Angular 2 CLI also switched to Webpack recently.
The reason why it’s so popular is that it’s very fast and extendable. Therefore, it can be adapted to a lot of different use-cases.

Here are some things that Webpack can do with very little configuration that would be impossible or very hard in the Rails asset pipeline:

Dead code removal – remove unused code to decrease the final JS size
Code splitting – break the code into multiple parts that can be loaded only when needed
Linting – stop the build process if there are some errors that might cause issues
Treat assets as modules – every asset (images, fonts, etc.) can be required and used anywhere

Webpack handles assets in a different way, which might be weird at first, but is very powerful. Your application has only one entry point (in most cases this will be a JavaScript file), and from there, you can require all other files as you need them. You can include other JavaScript files, but also CSS, JPG, PNG, or any other format you want. The important thing is to define a loader for a specific file format, and you’re good to go.

What is out there

When we decided to use Webpack with Rails, we looked at the available options and tried a few. Although they were good, none of them covered all our use cases:

The Pixelated approach – It’s very similar to our approach, but the difference being in how assets are handled in production. Since they’re using the same fingerprint for all files, it means that it will change when any of the files changes. What that means is – if you change one icon and redeploy your site, the visitors will need to download all the assets again, even if nothing has changed for them. We think this is very inefficient, especially if you’re doing multiple deploys per day.
webpack-rails gem – It requires you to change how you’re using the assets from the Rails side. It also has a very specific (tightly coupled) setup that might limit us in some situations.
webpack-assets gem – The whole configuration is done through Rails and it makes some assumptions about your client-side setup
webpack-manifest-plugin – this plugin was our starting point, but we realized there were some features missing, like the very powerful mapAssetPath that allows us to do manual adjustments in some cases that aren’t covered out of the box.

Rails 5.1

It was announced a few weeks ago that Rails 5.1 will get an official (but experimental) support for Webpack. The release date for Rails 5.1 is still unknown. Given that Rails 5 was released in June, and the current progress of 5.1 is just above 50%, it might still be a while before you’ll be able to use it.

The missing link

Our approach was simple – find a common ground for communication between Webpack and Rails. With this approach, we’re avoiding the tight coupling – Rails doesn’t know much about Webpack, and Webpack doesn’t know a lot about Rails. There are two parts of the solution:

The Webpack part

Webpack will be responsible for all the assets in the project. Since it will also add fingerprints to the files, we’ll need to let Rails know what the new files are, and to which folders they’re saved. To make this part simple, we created webpack-asset-pipeline. The plugin will intercept all requires and imports from your JS and CSS and add them to the manifest JSON file:

var WebpackAssetPipeline = require(’webpack-asset-pipeline’);

module.exports = {
  // The usual Webpack configuration
  entry: ’main.js’,
  // etc.

  plugins: [
    new WebpackAssetPipeline()
  ],
  output: {
    path: ’public/’,
    publicPath: ’/’,
    filename: ’[name].js’
  }
}

When you run Webpack, the plugin will create a manifest.json file that will contain all the asset mappings.

An example of JavaScript code with requires:

// application.js

require(’application.css’);
require(’images/file1.jpg’);
require(’images/file2.jpg’);
require(’images/file3.jpg’);

The mappings you’ll get in the manifest file:

{
  "application.js": "application-63eb3290f4d9a09812716b989a0808f3.js",
  "application.css": "application-07eb3299a08b981290763eb32962808f.css",
  "images/file1.jpg": "963eb32907744d9a0d6b98127162808f.jpg",
  "images/file2.jpg": "162808f4d9a0963eb3290774127d6b98.jpg",
  "images/file3.jpg": "d6b98127162969a0808f3eb32907744d.jpg"
}

To run Webpack on every relevant file change (for development), you should run it with the –watch flag:

webpack --watch

The Rails part

The only thing Ruby on Rails needs to do is to replace the assets helpers. This can be done in one of two ways (depending on your preferences). In both cases, you should remove Rails sprockets because they will not be used, and you won’t be able to use their methods by mistake. The easiest way to do this is with the following command when you’re creating your app:

rails new app --skip-sprockets

Adding a new `webpack_asset_url` helper

You’ll need a helper to replace the asset pipeline. Here is an example of how you can do this:

# app/helpers/webpack_helper.rb

module WebpackHelper
  def webpack_asset_url(asset)
    "/assets/#{manifest.fetch(asset)}"
  end

  def manifest
    @manifest ||= JSON.parse(File.read(’manifest.json’))
  rescue
    fail ’Please run webpack’
  end
end

An example how to use the helper:

<img src="#{webpack_asset_url(’logo.svg’)}" alt="logo" />

You’ll need to add the main JavaScript file to your layout with this helper. Also, keep in mind that you shouldn’t use Rails image_tag, stylesheet_link_tag or javascript_include_tag helpers.

Monkey patching Rails assets helpers

The second solution means a little more work in the start, but your application code will stay the same. Although removing sprockets is optional in the first method, in this case you have to remove them. The code for monkey patching is available in the plugin documentation.

After you’re done with monkey patching, you’ll be able to use the assets in the same way you used the asset pipeline:

= image_tag(’logo.svg’)

= stylesheet_link_tag ’application’, media: ’all’
= javascript_include_tag ’application’

Updated flow in combination with Webpack

Hot reloading

If you want to use all the features Webpack can offer, you can. One of the biggest features is hot reloading. Since JavaScript hot reloading depends on the JavaScript framework, this is out of scope for this blog post, but CSS hot reloading can be set up with relative ease:

Configuring Webpack

To use hot reloading, all assets will need to be served from the Webpack server. To work correctly with the rest of the setup, you’ll need to proxy the rest through the Webpack server to your original app server. For that, you can use webpack-dev-server, or if you need more control, webpack-dev-middleware in combination with express. An example of how to configure the webpack-dev-middleware to enable CSS hot reloading is available in the webpack-express-dev-server-boilerplate.

You’ll also need to set the writeToFileEmit property in webpack-asset-pipeline to true to ensure the manifest is saved to disk and therefore accessible by the app server.

Request flow during development with hot reloading

Caveats

There are still some issues we didn’t solve, but they’re just features that are nice to have – nothing essential:

Running the server

Since both Webpack and Rails have their servers or watch commands, we’ll need to run them both at the same time. We can do this either by having two terminals running the processes or by using something like the foreman gem.

Requiring assets

A great thing about Webpack is that it only processes those files that are explicitly referenced in JavaScript or CSS. That works great as long as you don’t need the assets somewhere else (e.g. in Rails). If you need an asset in Rails, but not in JS/CSS, you’ll still need to require the file in JS so Webpack will know it has to process it. The best way to do this is to have a separate JS file where you require all the assets that are used in Rails, but not in JS/CSS.

What if I’m using some other framework instead of Rails?

You might not be using Rails on your projects, but the plugin could work just as well with other server-side frameworks like Laravel, Django, Spring or ASP.NET MVC – the only thing you’ll need to do yourself is write the helper that will be used to fetch the asset names from the manifest file.

Want to contribute?

We’re looking to cover as many platforms as possible, so if you created helpers for your framework, you can send us a pull request with instructions on how to set it up. I’m sure others will appreciate it.

The post Squeezing Webpack into Backend Frameworks appeared first on Infinum.

Web Components Building Blocks of the Future Web

Darko Kukovec — Thu, 27 Mar 2014 10:00:00 +0000

Every now and then a technology comes out that changes the web landscape. In 2008, Google announced Google Chrome, a simple but fast and powerful browser. Around the same time, HTML5 started to emerge and gave us access to a lot of new features. Now it’s time to embrace another new technology called Web Components.

Although users won’t notice Web Components, they are probably an equally big change for web developers. First, let’s start with some history so we have a better understanding of how Web Components came to be.

A brief history of web libraries

2005 – Dojo Toolkit is published with an innovative idea: widgets. With a few lines of code, developers can add complicated elements like graphs and dialogs to their web pages.
2006 – jQuery gives us an ability to write small plugins that can later be reused.
2008 – jQuery UI is released and gives us a set of widgets and effects
2009 – Initial release of AngularJS, a web framework with directives
2011 – Initial version of React (Facebook) is released, giving us the ability to build the page UI without worrying what framework is used on the rest of the page
2013 – Web Components draft is published, but because of a small browser support, they are still not ready for the prime-time

When Dojo Toolkit was published, developers saw the advantages of having reusable modules. Today, when we mention plugins on a web page, most of us think about jQuery plugins since they are used almost everywhere and can do almost anything.

AngularJS and React showed us the direction in which the web platform is moving, with web elements that aren’t just visuals, but have complex logic on their own.

Web Components

Similar to HTML5, Web Components is a name for a group of features:

Shadow DOM allows us to encapsulate DOM and CSS
HTML Templates are a way of having a clonable DOM that can be reused on the page
Custom elements can either create new or extend existing elements. That means that a developer can, for example, extend the input element to support only credit card number format or they can create a new element which will contain all the fields required for credit card payment.
HTML Imports are a way of including web components into the page without having them inline in the code

The interesting part is that web browsers already use web components. For example, datepicker or element are web components, they are usually just hidden from the developer.

Datepicker element and its source code

Datepicker element with its Shadow DOM displayed

What is the point of Web Components?

JavaScript widgets and plugins are fragmented because they rely on different libraries and frameworks that might not play nice together. Web Components are a way of standardizing widgets and plugins.

The great thing about Web Components is encapsulation and, therefore, reusability – they can be used with any library or framework. Web Components don’t even need to be UI components – they can even be libraries that expose some functionality.

One of the examples is polymer-ajax, which isn’t that useful but it gives us an idea what’s possible. Polymer-ajax is a web component that gives the developer a standard way of doing AJAX requests, so the developer doesn’t need to worry about browser quirks. It is something like $.ajax() in jQuery, but it doesn’t have any dependencies.

Browser support

Currently, the main issue with Web Components is that no browser supports them completely. Luckily, there are libraries like Polymer that polyfill missing native features and go out of the way if the browser supports the feature.

Polymer (Google) has two parts – one for creating web components, and another for using them.
Another Web Component library is X-Tag (Mozilla). The great thing about Web Components is that, no matter whether they were built with Polymer or X-Tags, they can seamlessly work together, and that exactly is the beauty of standardization.

Using the Polymer library, Web Components can be used in all evergreen browsers (the newest versions of Chrome, Firefox, Safari and Opera) and Internet Explorer 10 and newer. On mobile, web components will work on iOS6+, Chrome Mobile, Firefox Mobile and Android 4.4.

Older browsers like Internet Explorer 9 or Android Browser 4.3 don’t support Web Components, even with Polymer.
This means that Web Components aren’t ready for use on the web, but they can be used inside of a native wrapper if the app targets a supported browser or platform (iOS6+).

Although X-Tag library supports some older browsers for creating components, Polymer is required to use most of them and, therefore, the browser support is the same.

Alternatives

Web Components might not be ready for use yet, but there are some libraries that already make use of some similar patterns to achieve the DOM abstraction:

React has its own “Virtual DOM” and allows the developer to use something very similar to Web Components. Since it doesn’t try to simulate Web Components, browser support is much better (Internet Explorer 6+). React is currently used on the Instagram and Facebook commenting system.
AngularJS directives are very similar to web components but don’t use the Web Component standard in order to achieve better browser support (Internet Explorer 8+). Since AngularJS is Google’s playground for future features, it will surely move to real web components at some point.

The future

Web Components might not be the silver bullet that will solve all web development problems, but once they gain a big enough support, they will simplify the development and maintenance of web pages and apps.

I believe that in a few years embedding a YouTube video using a component or displaying your Facebook profile on your web page or blog with a component will be normal. Also, when reusing an element you don’t have to worry if the new code will mess up something else or the other way around, which will make web development much easier.

The post Web Components Building Blocks of the Future Web appeared first on Infinum.

Web Technologies for Desktop Development

Darko Kukovec — Mon, 28 Oct 2013 03:45:00 +0000

This Saturday, the second consecutive Webcamp Zagreb tech conference took place. This year, there were around 600 participants from Croatia and the region, and they could choose between 24 presentations.

Webcamp Zagreb is an annual developer conference organized by Croatian user groups that work with different web technologies like JavaScript, Ruby, Python, Java, .NET, PHP and others. One of the organizers is CodeAtSix.

CodeAtSix is a meetup we organize at Infinum that gathers developers interested in Ruby, Rails, Javascript, GIT, web and mobile app development in general.

Web technologies for desktop development

I had the opportunity to give a presentation titled Web Technologies for Desktop Development in front of more than 250 people. In the 20 minute presentation I talked about the options developers have when developing desktop hybrid apps.

Node-webkit

The majority of my talk was focused around node-webkit – a technology we use for developing desktop applications using Web technologies.

Node-webkit is a very powerful wrapper for hybrid desktop apps, which allows the developer to use the full power of Chromium. On the other hand, if the developer needs access to native functionality, node-webkit comes with node.js to help with that.

WebCamp 2013 was awesome

In the end, I would like to thank the Webcamp Zagreb organizers for an awesome conference. The schedule was tight, the organization top notch, and I’m very impressed with how they managed to bring together developers working with different technologies (typically known for flame wars) under one roof. That’s a real achievement.

I really hope the conference stays like this in the following years.

Yeah. That’s a unicorn

The post Web Technologies for Desktop Development appeared first on Infinum.