 Okay, good evening everyone. I'm going to go ahead and get started. Today we're going to solve the big mystery of whether Drupal can be the backend API for a desktop application. Before we dive in, I'd just like to give a brief overview of my experience, my background, as well as my co-presenter, Vince, who wasn't able to make it today. So I'm a principle full stack developer at Pegasystems. I'm also a CTO and co-founder of MyStar of Neverending Solutions. I have a deep experience in decoupled architecture. And in terms of education, I have a bachelor's in computer science from University of Rochester and a master's in technical entrepreneurship and management from the Southern Business School. I have over 10 years of experience in JavaScript, PHP, Python, as well as experience in Drupal 7 through 10. My co-presenter, Vince, is a developer at Neverending Solutions. His expertise is in UI UX. He got his bachelor's in computer engineering from Macquarie University in Uganda. And he also has over four years of experience in PHP, as well as experience in Drupal 7 through 10. So before we dive into the idea behind Drupal supporting a back-end application, I'd like to go over the idea of what a decoupled site is. So everyone's on the same page. So at a very high level, a decoupled site is when the content is separated from the front-end in terms of the components, look and feel of the site, what goes together to build the site that you're seeing. The front-end is completely separated from the data that gets pulled into the site to form the components and form the look and feel. So when those two things are separated at a very high level, a decoupled site is formed. So how I got experience in decoupled sites. I didn't start working on decoupled sites until I started at a media current. At media current, I was a lead on the media current website. So media current website said decoupled site. So I had to learn Gatsby and I had to learn how Gatsby pulled in information from Drupal, the Drupal back-end, and how it efficiently generated the site after every build. And as the information, the API endpoints changed, had to figure out the best ways to generate the site speedily, efficiently with a performance in mind. It didn't have any experience at all with decoupled sites before then. But working on that made me pretty much fall in love with decoupled architecture and it started opening my eyes to how powerful decoupled architecture can be and seeing Drupal as a content hub instead of just a website. So what really got me deeper and deeper into decoupled sites was as a lead at redeveloping the media current site, I was assigned a task of coming up with a plan to improve the site. So I had to come up with a way to improve the nature of how it was put together, whether it to be changing from the front end of Gatsby to a new stack site generator like next year or whether it be changing how the endpoints were exposed from the Drupal end. So I did extensive research through trial and error. I was able to learn all the components of what it took to build a very efficient decoupled site and present the idea to the media current team and CTO. The second thing that really showed me the power of decoupled sites was the Penn State project, another project that I was one of the leads on at media current. It is a very large and decoupled site, one of the largest in the world, if not the largest in the world, and working on this site seeing how Drupal could power a site of this size and continuously feed information and how the front end could have successful builds over and over successfully really showed me how powerful Drupal could be and inspired me. And that's how the idea started forming. So how they did it, a little bit more insight into the structure of how the decoupled site works. So on the Drupal end, JSON API is one method of exposing information via endpoints. There's other ways, but that's the most common way. So JSON API will expose all the information for nodes at specific endpoints and all the information associated with those nodes as well. So you'll get all the information you need to pull in on the front end. So the front end can either be in Gatsby, Next.js, or any other stack site generator that you want to use. What Next.js or Gatsby will do is it will query using GraphQL or whatever method that you want to use to query the information. It will query all the information from those endpoints and then pull that information into different components that are defined in the front end theme and the stack together to make up pages in the site. It will dynamically pull that information in. So the site represents an accurate depiction of all the information that's entered on the front end. And as the information on the front end changes, so if something is updated in a node, the information in the endpoint changes, Gatsby will see that, rebuild the site, the front end is updated. So at a very high level, that's how the magic behind decoupled sites work. So the big question that we have here today is, can a similar concept work for desktop applications? Can we utilize a concept like that to spin up desktop application as a web developer? The answer so far is maybe. We don't want to give any spoilers yet, so the answer is maybe. So do we have any questions so far? Okay, if not, we can continue. So how do we accomplish this? So we'll need to have an app idea that can challenge Drupal in a way to see if it can be a successful back end application to not a simple desktop application, but a desktop application that offers at least a little bit of complexity. So the idea that started formulating has to do with desktop application privacy, which we'll go into in the next slide. But the stack which we'll also dive into is Drupal, ElectronJS, using the Quasar framework React as well as AWS S3 storage. So the app idea. So the idea formulated with me identifying a need and a market. So privacy is very important to write. That's why VPNs became so popular with internet privacy. So I noticed this need for desktop applications. So desktop applications can access any files on your computer. They can access personal information, whatever they want. A lot of people don't realize this. So narrowing down that segment into the gaming segment, a lot of gamers realize this and they complain about it constantly and there's not too many solutions for this. Narrowing down the segment, even more specific game Overwatch, which I heard a lot of complaints about the game, saving people's personal information and just completely storing it and being able to track anyone that downloads them in the game. A lot of people were upset with this and they wanted privacy. And it's an easy problem to solve. There's a very easy problem to solve with JavaScript. You just need to be able to build a desktop application and be able to reset those values. It's that simple. But as a Drupal developer, not able to easily build a desktop application, I felt like I was pretty much limited to Drupal. So that was the idea. These are just some simple values you can change with JavaScript or using Windows PowerShell commands or registry edits, which you can access through JavaScript Node.js. So JavaScript front-end developer can change a lot of these values and these are values that games, desktop applications read consistently and save for about users. So that's the app idea in terms of features of the app. But the features that Drupal can support. So let's say you want the app to not be free. Let's say you want to have it be on a subscription basis, access key basis. Can Drupal support this? Let's say you want to have people be able to buy the application for a day, a week, a month and use Drupal as the backend API for that. Who knows if Drupal can support it, but that's a requirement that we'd want for the idea. We also want the application to be able to handle registration. So users should be able to open the application, register the application, and then when they register the application, a Drupal user entity should be able to be created based on the information that they enter in the application. Hopefully Drupal can support this. Who knows? If they can register, we also want Drupal to be able to support the login. So after they register, they should be able to use the credentials that they registered with to be able to login and validate the credentials. So if they match the user credentials, username and password, that's within the Drupal database. They should be able to login as that user and gain access to the application. So we'd want Drupal to be able to support this or also be able to support this. There's a lot that we're already asking of Drupal. Going back to Electron, so as a Drupal front-end developer that knows JavaScript, I wanted to find an easy way to build a desktop application without having to reinvent the wheel and learn something new. I know JavaScript, so figured out that you can use JavaScript to build desktop applications with a framework called Electron. But I still didn't want to learn all the intricacies that Electron offered, and it felt like it would take way too long. So did a little bit more research and found a framework called Quasar. So with this framework, you can actually generate an Electron application with just a few commands. You just have to install the NPM dependencies with Yarn. And you can just, with one command, you can generate a desktop application template just like that. So that saves me time. And then with the front-end of the application, what's even better is that it offers an extensive library of components that you can utilize, just to plug and play. So if you wanted to build, let's say, a login functionality with a field and buttons, you can just pull in those components using the framework, and you don't have to build them from scratch using Vue.js or React or whatever you want to use. You can just use those components using the library, pull them in, and you already have all the components that can put together the front-end of the application. And the next thing you'd have to do is just tweak the CSS a little bit and then you can make it look exactly how you want the application to look. So that was the option I went with, just to save time, because I did not want to reinvent the wheel. I didn't want to spoil it, so at this point it's going to be a little bit of a spoiler. So Drupal is in the stack, so it may be a spoiler to hint that it maybe couldn't accomplish this. So the reason why we ended up using Drupal is because that is where our expertise is at. Drupal already proved itself within PSU and previous projects that I worked on, that it's a very big powerhouse that can handle whatever we put in front of it as a challenge. So it also offers scalability. So if more and more users join the application, Drupal can handle it very well if we want to populate the application with many access keys. Drupal will handle it very well. It's very good at handling structured data and it can scale very well and easily. So that's the main reason we chose Drupal. So AWS S3, this is a more simple reason for choosing this. So if we wanted the Electron application to offer automatic updates, you can easily integrate automatic updates using Electron. The main thing you have to do is point the Electron application to a public URL and so we use semantic versioning. So all the Electron application will do is look and check to see if the installer within the URL, so the public file path, if the installer has a version that's greater than the current version, it will prompt the client that there's an update and they can just click Install Update and then the updated code is automatically downloaded on the user's computer just from that. So we use S3 to push updates or if there's a new update to the app, we just put it into S3 and then all the users using the application will see there's an update, they download it and they get the latest version of the code. So the interesting, we're starting to get into an interesting part now, so how Drupal would power the access key portion of the application. So there's many ways to do this. The way we did it was we created a custom access key content type and with one field, we used a key value pair field. So there's three types of keys, day keys, week keys, month keys. Very simple. The type of key would go into the key field and the value of the key, which would be just name of the application just a random string goes into the value. If a key is redeemed, the node is unpublished. Very simple, easy way to handle if a key is live or not live. Next thing we'd have to change is adding a few fields to the user, the user entity. Because the users are the ones who redeem the keys, we'd want to be able to associate specific information with them. So the first thing and one of the most important things is adding a date field onto the user entity and that's going to represent the key expiration date. So very self-explanatory if a user redeems a key, if it's a day key, the expiration date would be added to that field. The next field is a little bit more complicated. It's called a hardware ID field and this solves an issue with account sharing. So I'm sure at least some people in this room have shared a Netflix account because they didn't want to buy one for themselves. This is good for the consumers obviously but it hurts the developers, people who sell the product and there's an easy way to solve this for desktop applications. So you're able to get unique identifiers off of computers like I was mentioning before. So we do this as well. We use commands from Node.js to get the unique identifier off of the desktop computer right as the access key is being redeemed and then it's saved into this field in Drupal. Now that we have that, if someone tries to log into that account using a random new computer or they try to share it, we can check if the access of the hardware ID value in this field is different than the one that's being checked and passed in from the front end then they don't get access as simple as that and that's the importance of that field. The last field that we added is another key value peer field to the user entity which represents the keys and that I use redeemed. So every single time they redeem my key we save the type of key, so the key, the value of the key as well as the date that the key was redeemed on. So there's two very useful contrib modules that we utilized for some of the REST UI functionality, the REST API functionality. So Drupal has built in REST API and it's not as easy to configure. REST UI makes it a lot easy, it provides us with a UI to configure different REST endpoints so we use this UI to configure the registration and login endpoints and any customization that would be needed there. We also use, utilize the RESTful logger module which is also a very helpful module because it pretty much tells you every single communication that goes from the client to the server which is huge because if there's a lot of users using the application you're going to want to monitor and know what they're trying to send into the back end and it's going to be very hard to tell unless you have a way of doing it, developing it yourself but the RESTful logger module gives you a view that shows every single request that gets sent to the back end with all the information about the request so what's sent in the request the information about the computer like the IP address that is coming from the request so anything you'll need to know to monitor what's going on between the client and server is logged within the RESTful logger module and you get that functionality just by installing the module which was very helpful and it was a huge time saver. So this slide is learning from so learning from my mistakes so being comfortable with decoupled sites I relied on JSON API a lot and I just by default I just was so used to making everything public and then just querying information from those public endpoints and doing whatever I wanted with it so security didn't really come to my mind when I was working on this so I exposed some information like access keys all the access keys that people would want to buy they're exposed publicly at a specific endpoint and a few pieces of user information was also exposed at an endpoint so I treated it kind of like a decoupled site because my expertise was in decoupled sites this obviously is very bad very insecure you don't want to expose all this information to the public so after talking with some developers I was able to quickly fix this and realize how big of a mistake this was and how I saw this was creating custom endpoints to resolve that issue so I was able to remove all the public endpoints and Drupal actually allows us to create custom endpoints through plugins so if you look at the code on the right side simple simple plugin that you can use to create the custom endpoints and in the URL path of string you can see you can define what the endpoint is so the front end would just send the request to that endpoint and then the information that the front end sends in would be in that access key string at the end so with this with this endpoint I'll go into a little bit more detail about the power that you can do just from PHP in this one plugin so access key that's passed in from the front end and it looks like one string and it is one string but multiple things can be passed in that one string so what the front end actually does is pass in three values in that one string and separates those three values with a specific separator so there is going to be an order that the front end always sends these values in every single time and the order is in Drupal user ID dash dash the hardware ID dash dash access key those three values that's all we need to perform a lot of actions in terms of redeeming keys so once that's passed in with the PHP code we can just check the values split the strings based on the dash dash and assign those values based on assign those values to what they actually represent user ID HWID and access key so now that we have those three values we can check to see if that Drupal user exists if the Drupal user exists we can check to see if the access key exists so if it's a published so if it's published and available then we can check to see if the hardware ID passed in is equal to the hardware ID that's stored in the user table we have full access to everything within Drupal right this is in our custom plugin so we can do whatever we want so we can do that if all checks out we can add the time that's associated access key to the user's profile and then just add that it was redeemed within the key value pair field on the user profile so just like that we can perform complex actions such as redeeming keys just from a custom plugin and if we wanted to add a little bit more security behind it or extra checks we can do that as well the only thing limiting us here is just our comfortability with PHP so I'll leave the demo to the end in which I'll demo registration and login if anyone wants to see access key redemption they can stop by and touch base with me after just so we can get through the security part but does anyone have any questions so far? okay so I will continue to security so for security it's very important that we use SSL these certificates are very essential wouldn't think that it's important because not many people are going to be logging into the backend of the application especially in this case when there's not going to be content authors there's not going to be really many people besides administrators going into the backend but still essential to stick to the basics of security best practices because it will prevent security attacks that can happen in the future another thing that's even more important is API rate limiting so what this means is that we want to limit the amount of requests to a certain number that comes in in a certain amount in a certain time frame and we do this so the API does not or the backend does not get overloaded with more requests than it can handle because if it gets more requests than it can handle that will lead to security vulnerabilities IP address limiting and banning this goes with user input sanitation so I'll go over user input sanitation very quickly so with user input sanitation we want to be able to sanitize and control what's submitted from the front end so in the desktop application if someone tries to submit something malicious or something that's out of format we want the front end to be able to handle that and format that in such a way to prevent anything dangerous from being submitted from the backend but if there's an issue with the sanitation if something gets past the user sanitation or if we see someone trying to just submit inappropriate things over and over to the backend we can see the IP address that the requests are coming from and easily just ban them this is a functionality that's included in Drupal so we can ban the IP address and we can see the IP address like I mentioned before from the REST restful logger module so we can ban the IP address and prevent them or make it even harder for them to submit and do the malicious things that you're trying to do so that also goes hand in hand with limiting what the client can do so with limiting what the client can do REST endpoints this is where you understand PHP and the power behind what you can do in the plugin really works wonders so let's say that something somehow goes past the user sanitation and hits the endpoints as a Drupal developer you have full access to what is coming in to the endpoints so you can perform as many checks as you want to make sure the data coming in looks exactly how you want it to look before performing anything that could be harmful to the database and this creates a lot of limitation on what the client can do because we have the user input sanitation and then we have the extra validation checks we can do on the plugin end through PHP to make sure that we can prevent anything malicious from happening so as a worst case our worst case scenario we can also have geo filtering when we're under a DDoS attack and what when you're under DDoS attacks the attacks are pretty much from a singular area so if you filter traffic from that singular area there's a very high chance that the DDoS attack can end so as a worst case scenario you can utilize geo filtering as well so now that we discussed security on the Drupal end what's even what's just as important is the security on the electron application end and as a web developer this is not something that we're used to especially a JavaScript developer if you're writing JavaScript code or front end code you're used to the code it's used to being okay with the code being public things are usually open source supporting the community sharing code it's kind of in our nature with Drupal and with as front end developers but I realize the hard way that this is completely different within desktop application development especially if you work let's say once a year to build a desktop application you spent hundreds of hours to put together this code that has value that solves a problem for a specific customer base you want that code to be protected because someone can easily if it's not protected someone can easily steal your code, steal all that hard work and replicate it and this is something that I had to understand come to understand I'm mainly front end web or mainly full stack web developer focusing on Drupal it's completely different playing field with desktop app development so with electron apps you can actually right click on an electron app open file location and then the app is bundled into a .sr file and it stands for Adam Shell Archive Format and this offers level of protection and just because of the fact that people are unaware so if you see in a .sr file you're not going to think that you can extract anything out of it because it's not like a .zip file or .rar file or something that's common that you extract things out but if you do a little bit of research you can actually figure out you can download something called 7zip right click the .sr file and then extract the full source code using just a 7zip the code that you worked 6 months a year however long you spent they can get full access to it in 20 seconds just with 7zip and that's pretty scary so there's a few solutions to this one solution is a .sr armor so this is encryption for that .sr file this is available as an npm package it will encrypt the .sr file within the build process of electron so if someone trying to gain access to your code right clicks it and tries to extract with 7zip they'll actually get errors on top of errors but this is not a full proof solution obviously we have google someone can google how to bypass .sr armor protection and then they can just follow the guides so that's not enough you have to layer multiple things to fully protect yourself so the next thing is obfuscating the code so this is very powerful it turns the javascript code into something that's very unreadable it's very hard to reverse engineer it looks like a lot of zeros and x's i'll show what looks like in the next slide but this is still possible to reverse engineer this if someone was really persistent so my recommendation is adding a third layer of protection as well so using npm plugin to transform the javascript code into byte code so once you transform it into byte code then it's very hard to reverse engineer and you will be very safe you can feel very safe and confident with your code and it's highly unlikely that someone will be able to gain access to it so to show what this looks like so this is what it looks like if you use the obfuscator to secure your code very hard to tell what it's doing it's hard to reverse engineer this and then with the byte code everything turns into byte code besides strings so this to your actual code very very well protected so a combination of all three is what I recommend so any questions? ok so I will go over the demo now and I will show login and registration and then if anyone wants to see access key redemption and anything else I can show after the presentation so we will just enter username email and just a password click sign up and it will load for a bit and then we will check on the drupal site to see if this user entity is created so the next screen you will see is access key but we will refresh drupal site and as you can see on my drupal site a new drupal user is registered right here and we will see if I can login using this drupal user just by logging out and then I am logged in and then prompted for the access key and that that is the end of the presentation