ObjectSecurity is a highly innovative cybersecurity company headquartered in San Diego, CA

ObjectSecurity

Since the introduction of smart contract technology, Solidity has been the coding language of choice for smart contract developers. However, if you’re a Solidity developer, you already know it has drawbacks. Among other flaws, major security concerns can arise from the simple mishandling of certain data types, and there are no built-in access controls. A new smart contract language developed for the Flow blockchain, , learns from Solidity’s oversights and natively solves many of its inherent problems. And if you already know Solidity, it’s straightforward to learn! Cadence This article introduces the Cadence smart contract language, details how it improves over Solidity, and then walks through a side-by-side comparison of both languages on some common smart contract examples. By the end, you should be comfortable with Cadence and ready to get started on Flow! About Cadence Cadence is the programming language that powers the Flow blockchain, which was originally created by to support large-scale crypto games and NFT projects. (You’ve probably heard of NBA Top Shots—one of their most successful projects.) Its syntax might be familiar, since it was inspired by popular modern languages such as Swift, Rust, and Kotlin. Cadence is and , with a resource-oriented approach and capability-based security model. Dapper Labs statically strongly typed All of this means that Cadence is . highly optimized for digital asset creation and management The most substantial innovation Cadence introduces is its . This approach makes it significantly easier to create, track, and manage a user’s assets. Instead of relying on a central public ledger as the source of truth (as Ethereum does), assets are tied directly to a user’s account storage. So an asset created as a resource, such as an NFT, can only exist in one location at a time. This ensures they only have one owner—either an externally owned account or a smart contract. resource-based paradigm How Cadence Improves Over Solidity Cadence improves over Solidity in many ways. Let’s look at three examples—small coding mistakes, security and access control, and contract deployment. Those small coding mistakes Some of the biggest issues with Solidity usually stem from the smallest mistakes. For example, initializing a variable with just a default value—although convenient at times—can lead to unexpected results if that variable is not changed. And fixed-range data types can lead to potential underflow or overflow situations, which would be disastrous if that data type represents a monetary value. In Cadence, variable values must be set upon initialization, removing any unwanted results from default values. Additionally, integers in Cadence are automatically checked for underflow or overflow conditions, whereas you would need to inherit OpenZeppelin’s or use a version higher than 0.8 with Solidity. safe math library Security and access control When it comes to security and access control, Solidity requires you to create custom modifiers or inherit other security-based smart contracts, but also has many functions that are public by default. With Cadence’s , accounts can only perform functions they have access to. This means Cadence has access control fundamentally built into the language itself. Also, methods defined on resource objects in Cadence cannot be susceptible to , something Solidity developers have to be keenly aware of when creating the flow of their logic. capability-based security model reentrancy attacks Smart contract deployment When issues in Solidity smart contracts are found, developers are unable to fix them without deploying an entirely new contract. And even then, the vulnerable contract still exists. Developers must ensure their user base switches over to the new contract. In Cadence, is built in and transparent. When the code is declared secure and final, the contract can be made immutable by removing the keys from the owner of the smart contract. smart contract upgradeability Overall, Cadence is a safer and more secure smart contract language that leaves less room for error. Now let’s look in detail at the differences between smart contracts written in Solidity and Cadence. We’ll walk through a simple Hello World contract and then a more complicated NFT implementation. Simple Contract Let’s start with an all-time classic. We’ve all written “Hello World” in multiple languages, so it’s an easy intro to Cadence. Let’s go through it step by step. Contract Definition First, we have the contract definition. The obvious difference is that the Cadence contract has an access control modifier: in this case, pub. This modifier ensures that everyone in the Flow network can access the contract, the default behavior for Solidity contracts. However, in Cadence, we could also set the access control to . This limits contract access to the . Here we already see a major difference between Flow and Ethereum. We don’t simply deploy contracts to the Flow blockchain; we deploy them to our account storage. On the Flow blockchain, each account is initialized with storage, where resources and structures can be stored. This storage has its own permissions, which allows us fine-grained control over who can execute the methods of our contract. access(account) account that deployed that contract Contract Variables The next line defines a string variable scoped to our contract. Semicolons are optional in Cadence, and a keyword is used to define the variable. let Cadence has two types of variables—mutable and immutable. Variables created with are immutable, or otherwise known as constants; we can only set them once, and they cannot be changed for the lifetime of the contract. We define mutable variables (ones that can be changed) with the keyword. let var In this case, we set the variable value in the init method, because Cadence ensures that this method is only called once for every contract deployment. Methods The Cadence equivalent to Solidity’s is the method. This method is called exactly once—at the time a contract is deployed. constructor init Inside the init method, we set the value for our greeting variable. While Solidity writes to contract variables by default, Cadence writes to local variables and requires you to use the self-object to access contract variables. This decision protects against you accidentally writing to a contract variable when making a typo. The second method of our contract returns the greeting variable. In both Cadence and Solidity, we have to declare access for the method to be public, and both languages require us to define the return type. In this case, it’s a string. But Solidity requires us to be more low-level here. It requires us to explicitly tell it where the string is located. It also makes us mark the functions as view, so that we don’t accidentally modify the state of the blockchain. Cadence, on the other hand, doesn’t need that low-level control, since it is strongly and statically typed. Potential errors are caught before the program is run on-chain, making the whole method declaration more readable by removing redundant keywords. NFT Contract Next, let’s look at a basic NFT contract from both languages: Since both languages have different approaches to this example, let’s look at them separately: first walking through the Solidity example, then Cadence. Solidity In Solidity, an NFT is basically a list of IDs. You must keep track of these IDs inside the smart contract and increment them manually to ensure uniqueness. Solidity doesn’t know anything about NFTs or their uniqueness. It’s just a list of IDs mapped to their owners, all managed manually within the contract. This leaves room for error if the ID incrementation is improperly handled, potentially resulting in multiple NFTs having identical IDs. In the example, the NFT doesn’t have any additional data attached, but you could add another mapping ID to a URI. The contract ensures every newly minted NFT is mapped to an owner's address. This is a simple example, of course. Usually, you would need to extend several interfaces to get a remotely secure NFT contract and features like metadata used to attach the well-known JPGs to your NFT, but the basic mechanisms are the same. Cadence Now, let’s look at the Cadence version and how it improves upon this Solidity example. Resource Definition The Cadence example starts with a resource type called . Notice the @ symbol in front of ? This symbol is required, as it ensures the usage and behavior of resource types will remain explicit. NFT NFT We can create instances from a resource, and it can have attributes just like a struct. The difference from a regular struct is that a resource is a special type that handles ownership in addition to the data it stores. Inside the resource type , there is an id field. The field is an integer, , and it is a unique id given to each NFT resource. This will be different for each NFT resource, meaning the resource cannot be duplicated or combined. Next, the field is initialized using the function. NFT id UInt64 id id init Similar to how ensures only one function can modify a variable, Cadence ensures the same for its resources. Rust’s borrow checker Resource Creation When we create a new resource, we have to move it around storage locations. Our smart contract will not run properly if we leave the resource as is, so this forces us to be deliberate with resources and their storage locations. This form of control also ensures that resources never get lost or accidentally deleted; they can only be in one location at a time. When we call the mint function, it will create a new instance of our resource. This function returns a resource with a type of and takes in the field, , from the resource that was defined earlier. The keyword is a bit like the new operator in object-oriented programming, creating a new resource. The , or move-operator, makes it explicit that this resource isn’t available at the source after we called it. NFT NFT id create <- Storing the Resource The variable will point to the account we used as a deployment target for our contract. As we learned before: smart contracts aren’t deployed in a global namespace on the Flow network, but in special on-chain storage that belongs to your account. So, the smart contract knows which account it’s been deployed to and can use that information in its methods. self.account In this example, we use the account’s save method. In the final function, we move the resource into the methods first argument and tell it which path inside the account should store our NFT. init save Since our NFT is a resource, no entity on the Flow network can copy it; we don’t have to keep track of its uniqueness explicitly. Summary Cadence is a fresh take on smart contract programming languages, optimized for asset creation and management. It’s a modern alternative that mitigates the deficiencies of Solidity through such means as forced management of variables and resources, security and access controls at a foundational level, and the ability to upgrade smart contracts before making them immutable. Cadence opens you to the possibilities of the Flow ecosystem, and incorporates many features from languages like Rust. So, if you are a developer looking to write smart contracts in a fundamentally safer and more secure language, Cadence is an excellent option. To learn more, check out the and . Cadence Documentation Flow Developer Portal Have a really great day!

Smart Contract Head to Head — Ethereum vs. Flow

Contrato inteligente frente a frente: Ethereum vs. Flow

Tête à tête de contrat intelligent - Ethereum contre Flow

स्मार्ट कॉन्ट्रैक्ट हेड टू हेड — एथेरियम बनाम फ्लो

スマート コントラクトの直接対決 — イーサリアム vs. フロー

Contrato Inteligente Frente a Frente — Ethereum vs. Flow

Hợp đồng thông minh đối đầu - Ethereum vs.

智能合约头对头——以太坊 vs. Flow

For our fintech development team, we actively use the microservice approach. Security of inter-service interaction is essential for us. In this article, I'll explain how Istio works and demonstrate how to use some of its security features with an example. I hope you learn something from this post. Keep on reading! Why do I require a service network in the first place? Istio is an open-source service mesh that layers transparently onto existing distributed applications. It combines everything needed to manage and configure inter-service communication: Secure service-to-service communication in a cluster with TLS encryption Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress And, while there are many open libraries available to implement these functions directly in the service code, Istio allows you to achieve the same results without adding anything to the service itself. Concerning Changes: Istio is growing by leaps and bounds, which is very visible in practice. There are times when you recall exactly how you configured some functionality, but there is already a manual with a description of the configuration of completely different, new objects on the official website. This occurred in Istio 1.4, for example, with the introduction of the new v1beta1 authorization policy, when many Istio RBAC objects were removed. Alternatively, in version 1.5, the approach to components was changed, and instead of the three old separate components Pilot, Galley, and Citadel, there was now only one common istiod. Many online setup tutorials may become obsolete as a result of these innovations. These points will be specifically highlighted later in the article. Istio is logically divided into two planes: the data plane and the control plane. The data plane is a collection of proxy servers (Envoy) that are added to the pod as sidecars. These proxy servers, which are configured from the control plane, provide and control all network communication between microservices. Service discovery, configuration, and certificate management are all provided by the Management Plane (istiod). It transforms Istio objects into Envoy-compatible configurations and distributes them in the data plane. You can manually add an envoy to the application pod or set up automatic addition using the Mutating Admission webhook that Istio setup. Put the label istio-injection=enabled on the required namespace to accomplish this. Istio will add a special init container to the pod, in addition to the proxy sidecar with the envoy, that will redirect combat traffic to the container with envoy. But how is this accomplished? There is no magic in this case, and it is implemented by installing additional iptables rules in the pod's network namespace. About resources consumption: In my experience, adding Istio in a small cluster of about 100 services increases response delays of microservices by ~2-3 ms, each envoy takes up about 40 MB of memory and CPU consumption increases by an average of 5%-7% per pod. Let's see in practice how the sidecar captures incoming and outgoing traffic from the container. To do this, let's take a look at the network space of a pod with an added Istio sidecar in more detail. Demo stand: As an example, I will use a newly created Kubernetes cluster that has Istio installed. It’s easy to run Kubernetes locally using : minikube Linux: curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube
sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/
minikube start --driver=<driver_name> // --driver=none will launch all docker containers directly on the local machine. MacOS: brew install minikube
minikube start --driver=<driver_name> You can download Istio’s demo profile from : the official website curl -L https://istio.io/downloadIstio | sh -
cd istio-1.6.3
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo To illustrate inter-service communication, I will use two microservices: product page and details. They both come in the standard Istio delivery to demonstrate their capabilities. Installing demo microservices: kubectl label namespace default istio-injection=enabled
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml Let's take a look at the container list in the product page application: kubectl -n default get pods productpage-v1-7df7cb7f86-ntwzz -o jsonpath="{.spec['containers','initContainers'][*].name}"
productpage 
istio-proxy 
istio-init In addition to the product page itself, the pod has a sidecar istio-proxy (the same envoy) and an init container istio-init. To view the iptables rules configured in the pod namespace, use the nsenter utility. To do this, we need to find out the pid of the container process: docker inspect k8s_productpage --format '{{ .State.Pid }}'
16286 We can now examine the iptables rules that have been configured in this container. It is clear that almost all incoming and outgoing traffic is now intercepted and redirected to ports where the envoy is already waiting. Enabling Mutual Traffic Encryption Istio 1.12 no longer includes the Policy and MeshPolicy objects. Instead, it is better to use the PeerAuthentication object. Istio enables you to encrypt all traffic between containers, and the applications will be unaware that they are communicating via tls. Because client certificates are already mounted in the proxy sidecars, Istio does this out of the box with just one manifest. The algorithm is as follows: Before sending requests, the client-side and server-side envoy proxies authenticate each other. If the verification is successful, the client proxy encrypts the traffic and sends it to the server proxy. The proxy server-side decrypts the traffic and locally redirects it to the actual destination service. You can enable mTLS at different levels: At the network-wide level At the namespace level At the level of a specific pod Operating Modes: PERMISSIVE: Both encrypted and plain text traffic is allowed; STRICT: Only TLS is allowed; DISABLE: Only plain text is allowed. Let's access the service details from the product-page pod using curl without TLS enabled and see what comes up in details using tcpdump: Request: Dumping the Traffic: In plain text, the entire body and headings are perfectly readable. Enable tls. Create an object of the PeerAuthentication type in the namespace with our pods to accomplish this. apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT Let's run the request from the product page to details again and see what we can get: Authorization: With the implementation of the new authorization policy, the ClusterRbacConfig, ServiceRole, and ServiceRoleBinding objects were . Instead, use the AuthorizationPolicy object. removed Istio can configure access from one application to another using authorization policies. Furthermore, unlike traditional Kubernetes network policies, this works at the L7 level. So, For example, you can fine-tune the request methods and paths for HTTP traffic. As we saw in the previous example, access is granted to all pods in the cluster by default. Using this yaml file, we will now prohibit all activities in the default namespace: apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {} And let's see if we can get through to the details service: curl details:9080
RBAC: access denied Great, now our request fails. So, now we'll configure access so that only the GET request, and only on the path /details, is allowed, and all other requests are rejected. There are several possibilities here: You can configure requests to pass with specific headers By the app's service account By outgoing ip address By outgoing namespace By claims in the JWT token The easiest thing to maintain is to give access to the application's service account; this has the advantage of not requiring pre-configuration because the demo application bookinfo already comes with the created and mounted service account. To use authorization policies based on service accounts, TLS mutual authentication must be enabled. Setting-Up a new access policy: apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "details-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: details
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/details/*"] And we try to reach out again: root@productpage-v1-6b64c44d7c-2fpkc:/# curl details:9080/details/0
{"id":0,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"} Everything works. Let's try other methods: root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XPOST details:9080/details/0
RBAC: access denied
root@productpage-v1-6b64c44d7c-2fpkc:/# 
root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XGET details:9080/ping
RBAC: access denied Conclusion Finally, I'd like to point out that the features discussed here represent only a small portion of what Istio is capable of. We received and configured inter-service traffic encryption and authorization out of the box but at the cost of adding additional components and, consequently, additional resource consumption.

Improving Security in your Microservices Architecture with Istio

Security is hard. Often when we build applications we want to allow only registered users to access the application. We want to be able to manage user accounts, see when they last logged in, be able to disable suspicious accounts and have a dashboard to view and manage all this data. We might also decide to support multi-factor authentication and social login. But security isn’t just hard, it also takes a while to implement. What if there’s a service that could take away this part of the development hassle from you? Why spend weeks or months rolling your own auth? This is where Auth0 shines. In this tutorial, I’ll show you how to build a chat application with Pusher, add user authentication with Auth0 Lock, and manage users from the Auth0 dashboard. Introduction to Auth0 and Pusher is an Authentication-as-a-Service (or Identity-as-a-Service) provider focused on encapsulating user authentication and management, which provides an SDK to allow developers to easily add authentication and manage users. Its user management dashboard allows for breach detection and multi-factor authentication, and Passwordless login. Auth0 ’s API’s and hosted infrastructure allow us to build scalable and reliable realtime applications. Pusher has a concept of channels and events which are fundamental to it. Channels provide a way of filtering data and controlling access to different streams of information, while events are the primary method of packaging messages in the Pusher system and form the basis of all communication. Pusher Building the application We will be building a chat application that’ll allow users to communicate with each other where everyone sees every other person’s messages. It’ll work similarly to how channels work in Slack: just one channel for everybody to communicate. Here’s what we’ll be building: Final App Setting up the backend We’ll start by building the backend which will facilitate receiving and broadcasting chat messages, serving static files, and also setting up Auth0 and Pusher. First, you’ll need to signup for a Pusher and Auth0 account. Go to and and sign up for an account. To use Pusher API we have to signup and create a Pusher app from the dashboard. We can create as many applications as we want and each one will get an application id and secret key which we’ll use to initialise a Pusher instance on client or server side code. pusher.com auth0.com Create a new Pusher account To create a new Pusher app, click the side menu, then click the button below the drawer. This brings up the setup wizard. Your apps Create a new app 1. Enter a name for the application. In this case I’ll call it “chat”.2. Select a cluster.3. Select the option “Create app for multiple environments” if you want to have different instances for development, staging and production.4. Select as the frontend and as the backend.5. Complete the process by clicking `Create App` button to set up your app instance. Vanilla JS NodeJS Create new app on Pusher Since we’re building our backend in Node using Express, let’s initialise a new Node app and install the needed dependencies. Run the following command: 1. and select the default options2. to install express and the Pusher node package npm init npm i — save body-parser express pusher Add a new file called which will contain logic to authenticate the Pusher client and also render the static files we’ll be adding later. This file will contain the content below: server.js var express = require(‘express’);var bodyParser = require(‘body-parser’);var Pusher = require(‘pusher’); var app = express();app.use(bodyParser.json());app.use(bodyParser.urlencoded({ extended: false })); var pusher = new Pusher({ appId: APP_ID, key: APP_KEY, secret: APP_SECRET, cluster: eu }); app.post(‘/pusher/auth’, function(req, res) {var socketId = req.body.socket_id;var channel = req.body.channel_name;var auth = pusher.authenticate(socketId, channel);res.send(auth);}); app.post(‘/message’, function(req, res) {var message = req.body.message;var name = req.body.name;pusher.trigger( ‘private-chat’, ‘message-added’, { message, name });res.sendStatus(200);}); app.get(‘/’,function(req,res){res.sendFile(‘/public/index.html’, {root: __dirname });}); app.use(express.static(__dirname + ‘/public’)); var port = process.env.PORT || 5000;app.listen(port, function () {console.log(`app listening on port ${port}!`)}); We instantiate Pusher by passing in an object that contains the details of our app ID and secret key, which can be found on the tab in your Pusher dashboard. Pusher also provides a mechanism for authenticating users to a channel at the point of subscription. To do this, we expose an endpoint on the server that will validate the request and respond with a success or failure. This endpoint will be called by Pusher client libraries and can be named anything. We used the default name for this endpoint on Pusher, which is . The line authenticates the client with Pusher and returns an authentication code to the calling client. App Keys /pusher/auth var auth = pusher.authenticate(socketId, channel); To allow this file to run when we start npm, we update with the following value: package.json “scripts”: {“start”: “node server.js”,“test”: “echo \”Error: no test specified\” && exit 1"} To create an Auth0 client Create an Auth0 client 1. Select from the side menu.2. On the new page, click the button3. Enter a name for the app and select as an option4. Click the button to create the client. Clients Create Client Single Page App Create An Auth0 client provides us with Client Id and Secret which we’ll use to interact with Auth0 from the code. On the settings tab, we can see the Name, Client Id, Secret, Client Type and many more. I want to enable CORS for my domain , set the log out URL and the URL to redirect to after the user has been authenticated with Auth0. Update the following settings with http://localhost:5000 http://localhost:5000 1. Allowed Callback URLs2. Allowed Logout URLs3. Allowed Origins (CORS) Building the frontend With the backend all good to go, we build the web page that will facilitate messaging. Create a folder named which will contain the html and javascript file. Create two new files and with the following content: public style.css index.html style.css url(" ");.chat{list-style: none;margin: 0;padding: 0;}.chat li{margin-bottom: 10px;padding-bottom: 5px;border-bottom: 1px dotted #B3A9A9;}.chat li.left .chat-body{margin-left: 60px;}.chat li.right .chat-body{margin-right: 60px;} @import http://netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css .chat li .chat-body p  
{  
    margin: 0;  
    color: #777777;  
}  
.panel .slidedown .glyphicon, .chat .glyphicon  
{  
    margin-right: 5px;  
}  
.body-panel  
{  
    overflow-y: scroll;  
    height: 250px;  
}  
::-webkit-scrollbar-track  
{  
    -webkit-box-shadow: inset 0 0 6px rgba(0,0,0,0.3);  
    background-color: #F5F5F5;  
}  
::-webkit-scrollbar  
{  
    width: 12px;  
    background-color: #F5F5F5;  
}  
::-webkit-scrollbar-thumb  
{  
    -webkit-box-shadow: inset 0 0 6px rgba(0,0,0,.3);  
    background-color: #555;  
} index.html <!DOCTYPE html><html><head><link rel="stylesheet" href=" " integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous"><link rel="stylesheet" href=" " integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous"><scriptsrc=" "integrity="sha256-BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44="crossorigin="anonymous"></script><script src=" " integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script><link rel="stylesheet" href="style.css"><script src=" "></script><script src=" "></script><script src="index.js"></script></head><body><div class="container"><div class="row form-group"><div class="col-xs-12 col-md-offset-2 col-md-8 col-lg-8 col-lg-offset-2"><div class="panel panel-primary"><div class="panel-heading"><span class="glyphicon glyphicon-comment"></span> <span id="username"></span><div class="btn-group pull-right"><button type="button" class="btn btn-default btn-xs dropdown-toggle" data-toggle="dropdown"><span class="glyphicon glyphicon-chevron-down"></span></button><ul class="dropdown-menu slidedown"><li><a><span class="glyphicon glyphicon-refresh"></span>Refresh</a></li><li><a><span class="glyphicon glyphicon-ok-sign"></span>Available</a></li><li><a><span class="glyphicon glyphicon-remove"></span>Busy</a></li><li><a><span class="glyphicon glyphicon-time"></span>Away</a></li><li class="divider"></li><li><a id="logout"><span class="glyphicon glyphicon-off"></span>Sign Out</a></li></ul></div></div><div class="panel-body body-panel"><ul class="chat"> http://bootsnipp.com/snippets/6eWd https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css https://code.jquery.com/jquery-2.2.4.min.js https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js https://cdn.auth0.com/js/lock/10.18.0/lock.min.js https://js.pusher.com/4.0/pusher.min.js </ul>  
                </div>  
                <div class="panel-footer clearfix">  
                    <textarea id="message" class="form-control" rows="3"></textarea>  
                    <span class="col-lg-6 col-lg-offset-3 col-md-6 col-md-offset-3 col-xs-12" style="margin-top: 10px">  
                        <button class="btn btn-warning btn-lg btn-block" id="btn-chat">Send</button>  
                    </span>  
                </div>  
            </div>  
        </div>  
    </div>  
</div>  
<script id="new-message" type="text/template">  
    <li id="{{id}}" class="right clearfix">  
        <div class="chat-body clearfix">  
            <div class="header">  
                <small class="text-muted">{{name}}</small>  
            </div>  
            <p>  
                {{body}}  
            </p>  
        </div>  
    </li>  
</script>  
</body>  
</html> This file uses template from and also includes a script reference to Auth0 Lock . is a drop-in authentication widget that provides a standard set of behaviours required for login and a customisable user interface. It provides a simple way to integrate with Auth0 with very minimal configuration. bootsnip <script src=” https://cdn.auth0.com/js/lock/10.18.0/lock.min.js "></script> Lock We want to allow users to sign in when they enter the application and be able to send messages once they’re authenticated. Add a new file with the following content: index.js $(document).ready(function(){// Initiating our Auth0Locklet lock = new Auth0Lock(‘CLIENT_ID’,‘CLIENT_DOMAIN’,//example: lotus.auth0.com{auth: {params: {scope: ‘openid profile’}},autoclose: true,closable: false,rememberLastLogin: true}); let profile = JSON.parse(localStorage.getItem(‘profile’));let isAuthenticated = localStorage.getItem(‘isAuthenticated’); function updateValues(userProfile, authStatus) {profile = userProfile;isAuthenticated = authStatus;} if(!isAuthenticated && !window.location.hash){lock.show();//show Lock widget} // Listening for the authenticated eventlock.on(“authenticated”, function(authResult) {// Use the token in authResult to getUserInfo() and save it to localStoragelock.getUserInfo(authResult.accessToken, function(error, profile) {if (error) {// Handle errorreturn;} localStorage.setItem(‘accessToken’, authResult.accessToken);localStorage.setItem(‘profile’, JSON.stringify(profile));localStorage.setItem(‘isAuthenticated’, true);updateValues(profile, true);$(“#username”).html(profile.name);});});}); We initialise Lock by passing it the Client Id of the app, your user domain which starts with your username followed by or e.g . The widget is configurable and we can send in configuration options like , , and . Within the option we tell it to return the and claims. .auth0.com {YOUR_SELECTED_REGION}.auth0.com lotus.eu.auth0.com closable autoClose auth auth openid profile We check if the user is authenticated and show the widget when they’re not. Once the user is authenticated, Lock emits the `authenticated` event which we’ve subscribed to. When it’s raised, we store the user profile and other credentials to localStorage and set the user’s name to be displayed on the page. Once the user is authenticated, we want to connect to Pusher and send messages across. Update index.js with the following code: if(!isAuthenticated && !window.location.hash){lock.show();}else{ // Enable pusher logging — don’t include this in productionPusher.logToConsole = true; var pusher = new Pusher(‘APP_SECRET’, {cluster: ‘e.g eu’,encrypted: false}); var channel = pusher.subscribe(‘private-chat’);channel.bind(‘message-added’, onMessageAdded);} function onMessageAdded(data) {let template = $(“#new-message”).html();template = template.replace(“{{body}}”, data.message);template = template.replace(“{{name}}”, data.name); $(“.chat”).append(template);} Pusher is initialised with the and which you can get from the app dashboard on Pusher. We subscribe to a channel called . Pusher has 3 types of channels: Public, Private and Presence channel. Private and Presence channels let your server control access to the data you are broadcasting. Presence channels go further to force subscribers to register user information when subscribing. Private channels are named starting with and authenticated in the server when subscribing. APP_SECRET CLUSTER private-chat private- And finally we want to send the message to the user when they click send and also log them out when they select signout. Update with the code below index.js $(‘#btn-chat’).click(function(){const message = $(“#message”).val();$(“#message”).val(“”);//send message$.post( “ ”, { message, name: profile.name } );}); http://localhost:5000/message $(“#logout”).click((e) => {e.preventDefault();logout();}); function logout(){localStorage.clear();isAuthenticated = false;lock.logout({returnTo: “ ”});} http://localhost:5000 When the user clicks the send button, we take the message and put it in an object with the user’s profile name and send it to the endpoint on the server. When the logout button is clicked, it calls the logout function which clears the data stored in localStorage and call which logs the user out on Auth0 and redirects them back to our website. With all these additions, index.js should have the following content: /message lock.logout() $(document).ready(function(){// Initiating our Auth0Locklet lock = new Auth0Lock(‘CLIENT_ID’,‘CLIENT_DOMAIN’,{auth: {params: {scope: ‘openid profile’}},autoclose: true,closable: false,rememberLastLogin: true}); // Listening for the authenticated eventlock.on(“authenticated”, function(authResult) {// Use the token in authResult to getUserInfo() and save it to   localStoragelock.getUserInfo(authResult.accessToken, function(error, profile) {if (error) {// Handle errorconsole.log(error);return;} localStorage.setItem(‘accessToken’, authResult.accessToken);localStorage.setItem(‘profile’, JSON.stringify(profile));localStorage.setItem(‘isAuthenticated’, true);updateAuthenticationValues(profile, true);$(“#username”).html(profile.name);});}); let profile = JSON.parse(localStorage.getItem(‘profile’));let isAuthenticated = localStorage.getItem(‘isAuthenticated’); function updateAuthenticationValues(userProfile, authStatus) {profile = userProfile;isAuthenticated = authStatus;} $(“#logout”).click((e) => {e.preventDefault();logout();}); function logout(){localStorage.clear();isAuthenticated = false;lock.logout({returnTo: “ ”});} http://localhost:5000 function onMessageAdded(data) {let template = $(“#new-message”).html();template = template.replace(“{{body}}”, data.message);template = template.replace(“{{name}}”, data.name); $(“.chat”).append(template);} if(!isAuthenticated && !window.location.hash){lock.show();}else{if(profile){$(“#username”).html(profile.name);} // Enable pusher logging — don’t include this in productionPusher.logToConsole = true; var pusher = new Pusher(‘APP_SECRET’, {cluster: ‘eu’,encrypted: false}); var channel = pusher.subscribe(‘private-chat');channel.bind(‘message-added’, onMessageAdded); $(‘#btn-chat’).click(function(){const message = $(“#message”).val();$(“#message”).val(“”);//send message$.post( “ ”, { message, name: profile.name } );});}}); http://localhost:5000/message To test the app, run `npm start` on the terminal and open on two separate browsers. Here’s a run through of it: http://localhost:5000 Wrap Up This is an app to show how you can use Pusher to send messages in real-time and secure the channels, add user authentication and account management with Auth0, and easily integrate to Auth0 using Auth0 Lock. On your auth0 you can see the total number of users, logins and new signups. dashboard You can also see all your users when you click on the **Users** side menu. On this page you can see the list of your users and their mode of login. Selecting a user takes you to a more detailed page where you can take various actions on the account, for example, blocking an account or sending a verification email. Also on Pusher, you can go to your application dashboard, under the , where you’ll see statistics concerning your application, such as connection frequency and how many messages were sent through that app. The combination of these two technologies makes it faster and easier to build real-time secured applications. You can find the code here on . Stats GitHub This was originally published on Pusher

OBJECTSECURITY

objectsecurity.com

-- employees

Since n.d.

COMPANY RANKING

OBJECTSECURITY

EVERGREEN INDEX #8230

Representing this company? Click here to claim and customize this page!

ObjectSecurity WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

OBJECTSECURITY

objectsecurity.com

-- employees

Since n.d.

COMPANY RANKING

OBJECTSECURITY

EVERGREEN INDEX #8230

RELATED COMPANIESRANK

STORIES ABOUT OBJECTSECURITY

Representing this company? Click here to claim and customize this page!

ObjectSecurity WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!