In a previous blog post I discussed how to get basic cross-origin requests working for your Unity WebGL project. This post is meant as a quick follow-up to cover another tricky problem that may come up when attempting to host your Unity WebGL game on Kongregate: cookie-based session authentication. The Problem Let's say you have a backend API that uses cookies for session management. Your game works great when testing on your own domain, but breaks horribly once you host the files on Kongregate due to the fact that your API requests are now cross-domain and subject to strict CORS rules. This means that the browser will refuse to send cookies along with requests unless things are set up properly on both the client and the server. Keep in mind that this behavior is a good thing, as it means that it allows you to control what domains your session cookies will be sent to, which helps prevent this highly sensitive data from falling into the hands of malicious actors. Configuring the Server In order for the browser to allow

The Long Ago Kongregate has been around for a relatively long time. We were around when Flash was cool, and also when it became uncool. We were also around when SSL was considered an optional luxury that added significant overhead and latency to network requests. Thus, we built our site with the assumption that HTTP was a fine protocol to use most everywhere, and SSL should just be used "as needed" -- for authentication, purchasing, and other sensitive data. That assumption held up for over a decade, but in recent years there has been a large movement toward using SSL everywhere, with search engines and browser vendors alike starting to punish sites for serving up un-encrypted content. Visiting Kongregate using HTTP on modern browsers was starting to become a scary and confusing experience for our players, so we decided it was time to bite the bullet and switch to using HTTPS wherever possible. The Basic Challenge Converting to SSL can be a daunting task for even simple sites without much user-generated content. Here is a short list of

Let me tell you a tale about an initiative to reduce Flash dependencies on what used to be a "Flash gaming" site. This is the story about a large-scale project with the best possible outcome being that users don't notice any changes, and the worst possible outcome of everything breaking horribly. This, my friends, is the story of Kongregate's Death to Flashy initiative. In the Beginning When we first started building Kongregate, we didn't have to worry much about whether or not users had Flash installed. It was very much ubiquitous, and since you couldn't play most of the games on the site without it we could build features based on the assumption that Flash was available. We built our chat client in Flash, we created APIs for both ActionScript 2 and 3, games implemented them, and all was good. For a very long time, the vast majority of the games on Kongregate were made with Flash, even most of our externally hosted "iframe" games. Some of these external games eventually needed a way to interact

Many Unity developers have taken the plunge and started exporting WebGL versions of their games. Unfortunately, many of them also run into issues that can lead to performance degradation and instability. This is a particularly tricky problem on older machines that have less resources available. This article will outline several techniques for resolving some common WebGL performance issues we’ve seen with games published on Kongregate, and hopefully get you off to a good start when it comes to delivering a great plugin-free experience with your WebGL game. Measure Twice, Optimize Once One of the most common mistakes developers make when trying to optimize content is making assumptions about what is taking up lots of time or space. With Unity and WebGL this happens often when deciding how much heap space to allocate for the WebGL application in the player settings. Without doing research on the subject, it can be easy to assume that increasing the memory available to the application will lead to better performance. In reality you generally want to allocate the smallest amount of memory possible, which