DEV Community: Heertheeswaran V

SOLVED - SameSite Issue With Rails in Chrome

Heertheeswaran V — Wed, 30 Sep 2020 11:58:10 +0000

What is SameSite?

The SameSite attribute tells the browser when and how to use the cookie with first or third party applications. SameSite is used by most of the browsers to identify whether or not to allow cookies to be accessed.

The Values for SameSite attributes include

Lax - enables only the first-party cookies to be accessed.
Strict - enables only the first-party cookies and also does not allow request from an external site to access the cookies.
None - enables the cookies to be accessed by third parties/external sites.

Update In Chrome:

Previously, if the SameSite attribute is not set, it was defaulted to ‘none’ - which allows the third-party to access the cookies. Now, if the SameSite attribute is not set, Chrome defaults to ‘lax’ which allows only the first party to access the cookies.

So, if you need your application cookies to be accessed by a third party then we need to explicitly specify SameSite as ‘none’. In this case, we also need to specify Secure. Only if we explicitly specify ‘SameSite: None; Secure’, the cookies are shared to the third party.

How do we resolve this issue in Rails?

To resolve this issue in Rails, we need to explicitly set the cookies with SameSite=None and Secure. To set the SameSite and Secure we need to modify the session_store.rb.

config/initializers/session_store.rb

Rails.application.config.session_store :cookie_store, {
  :key => '_application_session',
  :domain => :all,
  :same_site => :none,
  :secure => :true,
  :tld_length => 2
}

The only catch is since we have specified the Secure attribute, the cookies will be shared only with the secured connection(HTTPS). In order to test this in your development environment, use ngrok.

That’s it! Your application will work perfectly in Chrome. Cheers!

Custom Domain Login in Ruby on Rails

Heertheeswaran V — Wed, 23 Sep 2020 04:58:21 +0000

Why Custom Domain?

Let’s take a scenario, in which an application https://app.example.org has to be accessed by multiple organizations (for instance, Org1 and Org2) with their own domain such as https://app.org1.org and https://app.org2.org. This can be achieved by introducing a custom domain (the domain in which the user wants to access the application) in the application.

To create a system with custom domain features, you have to maintain the session in a multi-domain environment. Handling sessions in this multi-domain environment is not simple, because the cookies are mapped to the domain to where it is set.

Setting up Custom Domain Session

Let’s take an example where the URL of the application is https://app.example.org and it has to be accessed with https://site.example1.org.

We will be using device authentication in this application. When we login with email and password there will be no confusion as the host is the same across all the actions. Also, the session was set by the domain accessed for the login. But, when we use omniauth logins such as Google or GitHub, there will be a difficulty as the callback URL can’t be set dynamically.

To overcome this difficulty, we follow the below-mentioned steps:

Set the device’s default user authentication to ‘omniauth’ authentication
In the callback action, redirect the custom domain (as Host) with a unique token (to identify the user) to the custom actions
In the custom action, the user is identified and logged in to the custom domain
Now, the session is set by the custom domain and the user can access the entire application
Here, the application (app.example.org) acts as the base for many other mini-applications (site.example1.org, etc.,).

Let’s see the above steps in detail with google login as an example. Let’s say that the Google Auth Callback URL is app.example.org/users/auth/google_oauth2/callback.

Omniauth Origin

In Omniauth, we have a parameter in the request which gives the origin URL of the authentication process. Let’s say we have the Sign In With Google Button in the_ /user/sign_in action. If the user clicks it from _app.example.org/user/sign_in, then this parameter will be the URL. This will be available in the following key request.env['omniauth.origin']. With this, we can find the host/domain of the request.

Custom Domain Login in Practice

When the user login with the custom domain URL https://site.example1.org/user/signin, the below Omniauth Callback action has to be performed:

Authenticate the user in the Application Level (across the application).
Find the Host from the Omniauth Origin. In this case, the host will be site.example1.org

URI.parse(request.env['omniauth.origin']).host)

Redirect to the custom action with the host as omniauth origin, along with the unique token to identify the authenticated user. Let’s call this custom action as social_login. To identify the user, we will encrypt the email as the unique token (as a parameter). So the redirect URL can be generated as "https://#{HOST}/user/social_login?key=#{user.encrypt_email}" and the redirect URL will be “https://site.example1.org/user/social_login?key=encrypted_key”.
In the Social Login action, we can identify the user by decrypting the email which was received as the parameter in the above step. After identifying the user, we can sign in the user with the device sign_in function. Now, the user’s session will be tied to the custom domain.

def social_login
  if params["key"].present?
    @user = User.find_by(
     email: User.decrypt(params["key"])
    )
    if @user.present?
      sign_in @user
      check_private_organizaiton
    else
      redirect_to root_path, notice: "Please try again!"
    end
  else
    redirect_to root_path, notice: "Please try again!"
  end
end

I hope this blog gives you an idea to maintain a session with a custom domain! Try it out and let me know what do you think at heerthees@skcript.com

Protobuf with GO

Heertheeswaran V — Tue, 22 Sep 2020 04:39:58 +0000

Hey fellow coders, this is the second post of my Go series. You can check my last blog if you want to know how to set up your Go workspace. In this article, we are going to see what Protocol Buffers are, data format and how to implement it in a Go-based application.

What is Protocol Buffer?

Protocol Buffer is a data format, like JSON and XML which stores the structured data that can be serialized and deserialized. It is a data format developed by Google. The main advantage of Protobuf is that it is much smaller than the other formats.

Protobuf is 3 to 10 times smaller and 20 to 100 times faster than XML.

Now, let’s take a football game and represent the data in XML, JSON, and Protobuf.

XML:

<game>
  <home>Real Madrid</home>
  <away>Barcelona</away>
  <venue>Santiago Bernabéu Stadium</venue>
  <date>26-10-2019</date>
</game>

JSON:

{
  "home": "Real Madrid",
  "away": "Barcelona",
  "venue": "Santiago Bernabéu Stadium",
  "date": "26-10-2019"
}

Protobuf:

[10 11 82 101 97 108 32 77 97 100 114 105 100 18 9 66 97 114 99 101 108 111 110 97 26 26 83 97 110 116 105 97 103 111 32 66 101 114 110 97 98 195 169 117 32 83 116 97 100 105 117 109 34 10 50 54 45 49 48 45 50 48 49 57]

The above shown protobuf format is the encoded byte of the string, starting from position 2 in the array. The string “Real Madrid” is spelled out: R = 82, e = 101 and so on.

To know about this encoding, please check out Google’s own documentation here: Proton Buffer Encoding.

At this scale, the size is mostly similar. But when we scale it to larger data, the size starts to show a huge difference.

So, now let’s bring Protobuf to our Go code.

Installing Packages

➜  go_workspace go get github.com/golang/protobuf
➜  go_workspace go get github.com/golang/protobuf/proto
➜  go_workspace go get -u github.com/golang/protobuf/protoc-gen-go
➜  go_workspace export PATH=$PATH:$GOPATH/bin

This will install the necessary packages and we are now ready.

Now, let’s go and define the protobuf for the game object.

Game.proto

syntax = "proto3";

package main;

message Game {
  string home = 1;
  string away = 2;
  string venue = 3;
  string date = 4;
}

We start by specifying the version syntax of proto. Here we set syntax to ‘proto3’. Next, we define the package in which this object is to be used. After that, we will define the format of our Game object. This consists of our message format of type Game which features the following fields, home, away, venue and date.

As we defined the proto file, we are going to compile it with the protoc.

➜  go_workspace/src protoc --go_out=. *.proto

This will generate a game.pb.go file, which has the auto-generated code. For a detailed understanding of this code, check out Google’s documentation: Go generated code.

main.go

package main
import (
  fmt "fmt"
  "log"
  proto "github.com/golang/protobuf/proto"
)
func main() {
  elClasico := &Game{
    Home:  "Real Madrid",
    Away:  "Barcelona",
    Venue: "Santiago Bernabéu Stadium",
    Date:  "26-10-2019",
  }
  data, err := proto.Marshal(elClasico)
  if err != nil {
    log.Fatal("Marshaling error: ", err)
  }
  fmt.Println(data)
  newElClasico := &Game{}
  err = proto.Unmarshal(data, newElClasico)
  if err != nil {
    log.Fatal("UnMarshaling error: ", err)
  }
  fmt.Println(newElClasico.GetHome())
  fmt.Println(newElClasico.GetAway())
  fmt.Println(newElClasico.GetVenue())
  fmt.Println(newElClasico.GetDate())
}

In the above code, we use the Game struct defined in the game.pb.go to add details to the elClasico object. We use the Marshal function of the proto library to convert the object to the Protobuf format. Then the encoded bytes can be decoded with the Unmarshal function. Now we can use the function GetHome, GetAway generated in the game.pb.go file to get the values from the decoded object.

➜  go_workspace/src go run main.go game.pb.go
[10 11 82 101 97 108 32 77 97 100 114 105 100 18 9 66 97 114 99 101 108 111 110 97 26 26 83 97 110 116 105 97 103 111 32 66 101 114 110 97 98 195 169 117 32 83 116 97 100 105 117 109 34 10 50 54 45 49 48 45 50 48 49 57]
Home:  Real Madrid
Away:  Barcelona
Venue:  Santiago Bernabéu Stadium
Date:  26-10-2019

Don’t forget to include the game.pb.go. Now we have a small example up and running. But actually in the real world, the data is not going to be this simple. Now let’s see some nested fields.

We will use the same Game object. In this, we are taking the fields home and away and making it an object Team.

game.proto:

syntax = "proto3";
package main;
message Team {
  string home = 1;
  string away = 2;
}
message Game {
  Team team = 1;
  string venue = 2;
  string date = 3;
}

So again, we create the auto-generated code.

➜  go_workspace/src protoc --go_out=. *.proto

And we update the main.go file correspondingly.

main.go

package main
import (
  fmt "fmt"
  "log"
  proto "github.com/golang/protobuf/proto"
)
func main() {
  elClasico := &Game{
    Venue: "Santiago Bernabéu Stadium",
    Date:  "26-10-2019",
    Team: &Team{
      Home: "Real Madrid",
      Away: "Barcelona",
    },
  }
  data, err := proto.Marshal(elClasico)
  if err != nil {
    log.Fatal("marshaling error: ", err)
  }
  fmt.Println(data)
  newElClasico := &Game{}
  err = proto.Unmarshal(data, newElClasico)
  if err != nil {
    log.Fatal("unmarshaling error: ", err)
  }
  fmt.Println("Home: ", newElClasico.Team.GetHome())
  fmt.Println("Away: ", newElClasico.Team.GetAway())
  fmt.Println("Venue: ", newElClasico.GetVenue())
  fmt.Println("Date: ", newElClasico.GetDate())
}

Now if we run the program.

➜  go_workspace/src go run main.go game.pb.go
[10 24 10 11 82 101 97 108 32 77 97 100 114 105 100 18 9 66 97 114 99 101 108 111 110 97 18 26 83 97 110 116 105 97 103 111 32 66 101 114 110 97 98 195 169 117 32 83 116 97 100 105 117 109 26 10 50 54 45 49 48 45 50 48 49 57]
Home:  Real Madrid
Away:  Barcelona
Venue:  Santiago Bernabéu Stadium
Date:  26-10-2019

Interesting, isn’t it?

Alright guys, we now know how to use protocol buffer data format with Go. That’s it for now. Will meet you guys again with another interesting topic.

Django for Rails Developers

Heertheeswaran V — Sun, 20 Sep 2020 04:28:01 +0000

For the past 3 years, I’ve worked on both Rails and Django. Though Rails is my favorite (Yes, Swaathi made me write this), I would like to show you how similar and sometimes strikingly different both are. This article helps any Rails dev easily port over to Django. Well, what are we waiting for, let’s get started! :D

Installation:

Make sure you have Python (at least 3) installed.
Then just do this,

Rails	Django
`gem install rails`	`pip install django`

So similar!

Architecture:

Rails follows the MVC (Model, View, Controller) architecture. The Model is a representation of the database structure that is encapsulated in the host language. The Controller acts as an interface between the outside and inside world of a web framework. This is basically where requests are received and processed before responding. The View is a template that is shown to the user.

Django follows MVT (Model, View, Template) architecture. Here the view acts as the Rails controller and the template acts as the Rails view - I know, confusing!

Create App:

Rails uses “app” to represent the working directory. Whereas in Django, “project” is used.

Rails	Django
`rails new`	`django-admin startproject`

Run Development Server:

Both Rails and Django come bundled with a local web server. The default port is 8000 in Django and 3000 in Rails. The Django server is a light weight server purely written in Python where as in Rails the server is a Puma web server.

Rails	Django
`rails server`	`python manage.py runserver`

Settings.py:

Settings.py is similar to application.rb where we have the configurations of the project. In Django, all the configurations like database connection, timezone, template location, allowed hosts and so on are added to settings.py.

Manage.py:

Manage.py is the most important file when it comes to Django. This manage.py has the core functions required like makemigrations, migrate, runserver and so on.

Migrations:

Unlike Rails the migrations in Django need two steps. Those are “make migration” and “run migration”. In Rails, we create migrations for the models at the entire application level. But in Django we need to write all the fields required and the models methods in the model.py of the corresponding app.

Note: Initially, we need to run the migrate command to run the default migrations.

Rails	Django
`rails db:migrate`	`python manage.py makemigrations` `python manage.py migrate`

Models:

Both in Rails and Django models function as the same except for the fact that the fields of the model have to be mentioned in the model file in Django. But similar to Rails, we include the model methods and validations in the model file. In Django, model files are created in the app’s root directory.

View:

In Django views are similar to the controller in Rails. They act as the interface between the model and template. We define the actions in the views.py in the corresponding app directory similarly like controllers in rails.

Template:

In Django templates are similar as Views in Rails. In Django, Jinja2 is followed for the template format. Here all the templates are kept, in the template folder of each app’s root directory. Jinja2 is a template engine user in Django. Each view in Django returns an object which contains the data required in the template. Only the data available in the return object is accessible by the template, like the instance variable in rails.

The basic elements in Jinja 2 are

1. {%....%} are for statements
2. {{....}} are expressions used to print to template output
3. {#....#} are for comments which are not included in the template output
4. #....## are used as line statements

URLs:

Urls.py are more like routes.rb in Rails. In Django, the URL specifies the view function for each path and action. The URLs corresponding to each app is available in the app’s root directory. Don’t forget to import views in the urls.py in the main project urls.py.

One of the main changes, that has to be considered while working on Django is that we need to import the necessary library files in each model, view, and URL, unlike in Rails where everything is included when the app executes.

I hope this gives a good idea for a Rails developer to get started with Django! Try it out and let me know what you think! :)

Using Bamboo to Send Emails in Phoenix

Heertheeswaran V — Fri, 18 Sep 2020 06:26:45 +0000

Hey people! I’m back with another article based on my Phoenix learning.

So to get to the point - in any application, one of the most important processes is sending emails to users. We are going to use the Bamboo library which supports all the major email providers and we can also use the HTML template for the email content.

Here we will see the following:

Setting up Bamboo
Sending users a welcome email once they sign up
Using HTML to compose an email

Ok, let’s get into this now. My main goal for this post is to have my app send a welcome email to the new signups. The app is a status management app that lets us know the current working status of fellow employees.

Setting up Bamboo:

We’ll get started by adding the Bamboo dependency to our project’s mix.exs file. Add bamboo to the deps and application function.

mix.exs
  def application do
    [mod: {WorkStatus.Application, []},
     applications: [... :bamboo]]
  end

  defp deps do
    [...
      {:bamboo, "~> 1.5"}
    ]
  end

Now, let us install the dependencies by using the command

$ mix deps.get

Let’s now define the “Mailer”, which is in charge of sending the email. We will create a mailer module in the “lib/workstatus (lib/:application)” named “mailer.ex”. Later on in this module, we will define a deliver function that will be responsible for delivering the email.

lib/workstatus/mailer.ex

defmodule Workstatus.Mailer do
  use Bamboo.Mailer, otp_app: :workstatus

end

Now let us configure our development environment to use the Bamboo.LocalAdapter. In the dev.exs, add the following,

config/dev.exs

config :workstatus, Workstatus.Mailer,
  adapter: Bamboo.LocalAdapter

Bamboo.LocalAdapter allows us to view the sent emails in the development with the Bamboo.EmailPreviewPlug. To configure this, let us add the “/sent_emails” route and forward it to the Bamboo.SentEmailViewerPlug. Let’s add this in our “routes.ex”.

lib/workstatus_web/router.ex

 if Mix.env == :dev do
    forward "/sent_emails", Bamboo.SentEmailViewerPlug
 end

This wraps up the setup required for the Bamboo. Now, let’s fire up our Phoenix server. If you get into any errors, please check the above steps once again.

$ mix phoenix.server

Adding the Mailer Functionality

Bamboo separates the delivery and the composition of the mail. The delivery will be performed by the Mailer module. Let’s create an Email module that will perform the composition.

Create a file called “email.ex” in the same directory of our Mailer module. We will import Bamboo.Email here, from which we will use the new_email function to compose our email.

Now, let’s create a function for welcoming users.

lib/workstatus/email.ex

defmodule Workstatus.Email do
  import Bamboo.Email

  def welcome_mail(user) do
    new_email(
      from: "no-reply@workstatus.com",
      to: user.email,
      subject: "Welcome to WorkStatus!",
      text_body: "Welcome to the WorkStatus!"
    )
  end
end

For now let us, leave it with the text body. Later on in this post, we will see how to use the html template to compose the email.

Now, let us add this in the users_controller where the sign_up is handled. To send the email, we will use the deliver function in the Bamboo library which will be imported in the Mailer module. Import both the Mailer and Email in the controller.

lib/workstatus_web/contorollers/auth_contoroller.ex

def signup(%{assigns: %{ueberauth_auth: auth}} = conn, params) do
  user_params = %{token: auth.credentials.token, email: auth.info.email, provider: "github"}

  changeset = User.changeset(%User{}, user_params)
  {:ok, user} = sign_in(conn, changeset)
  Email.welcome_mail(user)
  |> Mailer.deliver_later()
end

Now, once the user sign_up for the app, the welcome email will be sent. We can see the email that has been sent in the routes we defined earlier in the development environment.

We can see the sent_email as in the above screenshot. Next, let us see how we can use the HTML to compose the email.

Using HTML to compose email:

With HTML we can compose the email in a more elegant way. First, let’s create a view for our emails. Create a file “email_view.ex” in the views folder.

workstatus_web/views/email_view.ex

defmodule Workstatus.EmailView do
  use WorkstatusWeb, :view
end

Now let’s create the templates we need. Let’s start by creating our new email layout. Create a new “email.html.eex” in the layouts folder.

workstatus_web/templates/layouts/email.html.eex

<html>
  <head>
    <link rel="stylesheet" href="<%= static_url(Workstatus.Endpoint, "/css/style.css") %>">
  </head>
  <body>
    <div class="container"><%= render @view_module, @view_template, assigns %></div>
  </body>
</html>

Then we will create the template for our welcome_mail. Create a template in the templates/email folder called welcome_mail.html.eex

workstatus_web/templates/email/welcome_mail.html.eex

<p>Hi, <%= @user.name %></p>
<img src="/images/phoenix.png" alt="Phoenix Framework Logo"/>

Let’s update our mailer function to render the created template. The updated welcome_mail function looks like.

lib/workstatus/email.ex

defmodule Workstatus.Email do
  use Bamboo.Phoenix, view: Workstatus.EmailView
  import Bamboo.Email

  def welcome_mailer(user) do
    new_email
      |> from("no-reply@workstatus.com")
      |> to(user.email)
      |> subject("Welcome to WorkStatus!!")
      |> assign(:user, user)
      |> render("welcome_mail.html")
  end
end

Now the sent email looks like this,

This is a basic implementation of sending emails in Phoenix using Bamboo. This post is intended to be used as a Get Started guide. There are many more extensions and detailed explanations available in the Bamboo Docs.

Create a Microsoft Teams Bot with Ruby on Rails and REST API

Heertheeswaran V — Thu, 17 Sep 2020 11:35:13 +0000

In this tutorial, we are going to build a bot using Microsoft Azure and use it in Microsoft Teams to interact with our Ruby on Rails Application. As of now, Microsoft Bot Framework supports SDK kit for Node js and C#. We will use the REST API to interact with the bot and perform operations.

First, let’s start with creating a new app on the Azure platform,

Create an App on the Azure Platform

Log in to Azure Portal.
To create an app, go to Azure Active Directory -> App registrations -> New Registration.

Take a note of the App ID from the Overview section.

Go to Certificated & secrets -> New Client secret and give a name and set expires to Never and click on Add.

Take a note of the secret id generated as this cannot be viewed again.

So, we have built an app with which we are going to create a bot service.

Create a Bot Service

Click Create new resource link on the upper left-hand corner of the Azure portal, then select AI + Machine Learning > Web App bot.
Fill up the form that opens up. In the Microsoft App ID and password section, give the app id and client secret as the password.
After creating the bot, set the messaging endpoint to your Ruby on Rails API endpoint in the setting.
Create an OAuth Connection Settings, fill the form.
Authorization URL: https://login.microsoftonline.com/botframework.com/oauth2/v2.0/authorize
Token URL: https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Refresh URL: < YOUR REDIRECT URI >
Scopes: < YOUR REQUIRED SCOPES >
This OAuth Setting is required for your bot to work in MS Teams.
1. Test your bot in the Test Web Chat.

REST API

Since the bot and app are now set up in the Azure platform we are ready to work with them.

User Authorization

In order to authorize the app by user, the user is needed to be signed in and authorize the app with the link below.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&scope=YOUR_SCOPE&redirect_uri=YOUR_REDIRECT_URI&response_type=code

Bot Access Token

To request an access token to interact with the bot, use the below request. The response token is a Bearer token.

POST https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MICROSOFT-APP-ID&client_secret=MICROSOFT-APP-PASSWORD&scope=https://api.botframework.com/.default

Response:

{
"token_type":"Bearer",
"expires_in":3600,
"ext_expires_in":3600,
"access_token":"esadjnaskdnnaHs..."
}

Create a Conversation

After getting a token, you can create a conversation with the user. To establish a conversation, use the following request to get the conversation id.

POST < Service URL >/v3/conversations (https://smba.trafficmanager.net/in for  teams)
{
 "bot": {
   "id": "YOUR_BOT_ID",
   "name": "YOUR_BOT_NAME"
 },
 "members": [
   {
     "id": "USER_ID"
   }
 ],
 "channelData": {
   "tenant": {
     "id": "USERS_TENANT_ID"
   }
 }
}

Response:

{  
"id":"a:1sdadaa.."
}

After receiving the conversation, make a POST request to the activity to send a message like below.

POST < Service URL>/v3/conversatoins/< Conversation id >/activities
{
 "bot": {
   "id": "YOUR_BOT_ID",
   "name": "YOUR_BOT_NAME"
 },
 "members": [
   {
     "id": "USER_ID"
   }
 ],
 "channelData": {
   "tenant": {
     "id": "USERS_TENANT_ID"
   }
 }
}

Reply to Conversation:

In order to reply to a conversation with the following request, get the user id, name of the bot and user from the parameters of the initial message.

POST <ServiceURL>/v3 /conversations/{conversationId}/activities/{activityId}
Authorization Bearer "eysdsda.." 
{
        "type": "message",
        "from": {"id": "< BOT_USER_ID>", "name": "<BOT_USER_NAME>"},
        "conversation": {"id": "IlbyD8hQi5aGqAAz3qXfVp-5"},
        "recipient": {"id": "<Receiver_user_id", "name": "<Receiver_user_name>"},
        "text": "This is a reply message."
}

Updating a message:

In order to update a message that is already sent, make the following request. You can get the replytoID from the initial message parameters

PUT <ServiceURL>/v3 /conversations/{ReplytoID}

Authorization Bearer "eysdsda.." 

{

   "type": "message",

   "text": "This message has been updated"

}

Test the bot in Teams:

In order to test your bot in teams, you are required to add the Oauth connection as stated in the create a bot service section. Then you can just copy your bot app id and start a new conversation in teams with that id. Now you are all set to check your bot in Teams.

So that’s it, people here is how you can easily create a basic bot and interact with ROR application. If you have any questions, leave them in the comments below.

Setting up OAuth in Phoenix

Heertheeswaran V — Fri, 14 Aug 2020 06:02:26 +0000

So, it’s been like a month since I started learning Elixir and the Phoenix. Phoenix is a web framework powered by Elixir and the Erlang VM, which makes it fast.

In this post, we will see setting up “Sign in With Google” in a Phoenix application with Ueberauth. We will be using the ueberauth_google hex package to perform this.

I’m going to assume that you have created the Phoenix app and created a user model. It should look similar to this.

# user.ex
schema "users" do
    field :email, :string
    field :first_name, :string
    field :last_name, :string
    field :provider, :string
    field :picture, :string

    timestamps()
  end

Adding Dependencies

We will add the ueberauth_google dependency to the deps in the mix.exs. Now, the mix.ex file looks like this.

 defp deps do
    [
      {:phoenix, "~> 1.5.3"},
      {:phoenix_ecto, "~> 4.1"},
      {:ecto_sql, "~> 3.4"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_live_view, "~> 0.13.0"},
      {:floki, ">= 0.0.0", only: :test},
      {:phoenix_html, "~> 2.11"},
      {:phoenix_live_reload, "~> 1.2", only: :dev},
      {:phoenix_live_dashboard, "~> 0.2.0"},
      {:telemetry_metrics, "~> 0.4"},
      {:telemetry_poller, "~> 0.4"},
      {:gettext, "~> 0.11"},
      {:jason, "~> 1.0"},
      {:plug_cowboy, "~> 2.0"},
      {:ueberauth_google, "~> 0.9"}
    ]
end

Next we need to include this in the application function in the mix.exs. Now the application function looks like,

def application do
    [
      mod: {OAuthApp.Application, []},
      extra_applications: [:logger, :runtime_tools, :ueberauth_google],
    ]
end

After this run the following command to install the added dependencies. This will show the entire dependencies list including the ones we added now.

> mix deps.get

Create a Google Project

Create a Google project by following the steps given here. The Google app will generate the client_id and client_secret that we need to configure in our app. In the Google app configurations, set the redirect_uri as “http://localhost:4000/auth/google/callback/”.

Updating Configurations

We will now add the configuration of our google app in our Phoenix application. Add the client id, client secret, and redirect_uri to the config.exs file.

# Ueberauth Config
config :ueberauth, Ueberauth,
  providers: [
    google: {Ueberauth.Strategy.Google, [default_scope: "email profile"]}
  ]
config :ueberauth, Ueberauth.Strategy.Google.OAuth,
  client_id: "741231234148352289-e9asdasdmomm9lar1brbundnmfg3j80f04ntqt.apps.googleusercontent.com", # Dummy code
  client_secret: "33uWw8WnPsadsdsSas7rjaTnkYbwu6", # Dummy code
  redirect_uri: "http://localhost:4000/auth/google/callback"

Now we have done all the configurations needed, we will get into coding now.

Defining the Routes

We will add the routes for sign in with google. We need the define the following routes in the routes.ex:

OAuth Initiate - This initiates the OAuth process.
OAuth Callback - This route is the route defined as redirect_uri in the google app configuration. We will get the user details in this callback call.

We will add these routes with the scope “/auth”. The code to be added to the router.ex looks like where provide is Google here. We can also use the same routes for any other social sign we need.

scope "/auth", OAuthApp do
    pipe_through :browser

    get "/:provider", AuthController, :request
    get "/:provider/callback", AuthController, :callback
  end

Auth Controller

We will now create a controller to handle the OAuth process.

Inside the controllers folder, create a controller file called auth_controller.ex. We will define the callback function here.
We need to define two callback functions.
- OAuth Success Case
- OAuth Failure Case

OAuth Failure Case

The Ueberauth send the failure response in the below mentioned format. So, we need to define a callback function to match the failure pattern. If the “assigns” variable has the key “ueberauth_failure”, it indicates that the authorization failed.

def callback(%{assigns: %{ueberauth_failure: _fails}} = conn, _params) do
    conn
    |> put_flash(:error, "Failed to authenticate.")
    |> redirect(to: "/")
  end

OAuth Success Case

If the failure key is not present then the authorization is successful and it sends the oauth response in the key “ueberauth_auth” in the response. So, we need to define the callback function to match the response pattern.

Like in the code below, we can match the user information and send it to the user changeset and based on the use case either create or update the user details.

def callback(%{assigns: %{ueberauth_auth: auth}} = conn, _params) do
    user_params = %{
      first_name: auth.info.first_name,
      last_name: auth.info.last_name,
      email: auth.info.email,
      picture: auth.info.image,
      provider: "google"
    }

    changeset = User.changeset(%User{}, user_params)

    case insert_or_update_user(changeset) do
      {:ok, user} ->
        conn
        |> put_flash(:info, "Thank you for signing in!")
        |> put_session(:user_id, user.id)
        |> redirect(to: Routes.lobby_path(conn, :index))

      {:error, _reason} ->
        conn
        |> put_flash(:error, "Error signing in")
        |> redirect(to: Routes.page_path(conn, :index))
    end
  end

Yay! Now, you have successfully used Google OAuth to authenticate your users.

In this article, we discussed implementing Sign in with Google in our Phoenix application. Ueberauth provides OAuth for most of the social platforms such as Facebook, Twitter. WIth this we can also get the user token from the OAuth response and play with the Google APi to integrate google apps like Google Calendar, Google Meet. With this, the user does not have to remember a password which gives a good user experience.

If you find any difficulties, reach out to heerthees@skcript.com.

Build a Simple Web App using Go

Heertheeswaran V — Sun, 24 May 2020 14:57:01 +0000

Hello everyone, Today I would like to discuss building a simple hello world web app with Golang. Go is already has a web server built-in. The "net/http" package from the standard library contains all the things we need to do with the HTTP protocol. In this example, we will see how easy it is to run a web server that we can see in our browser.

For creating a webserver in go, we need to understand two main functions.

Request Handler

As the name suggests, the Request Handler is the one which receives all the http connections from the browser. The syntax of the Request Handler function is

func (w http.ResponseWriter, r *http.Request)

The handler function receives two arguments:

http.Request - contains all details about the HTTP request including things like the URL, header or body fields.
http.ResponseWriter - where we write out a response to.

So first, we need to register a Handler function.

Request Listener

The Request Handler function can only receive the http connections. Along with that, we need a Request Listener which listens on a port and passes the connection to the Handler function.

The syntax of a listner function is

http.ListenAndServe(":3000", nil)

The listener function receives two arguments:

port - The port to listen for the http connections.
handler - the handler to send all the connection. Typically the handler is nil.

Hello World Web App

By understanding the above function, it is simple to create a web server. The code for a simple hello world web server looks like this

// main.go
package main

import (
    "fmt"
    "net/http"
)
func main() {
  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!") 
  })
  http.ListenAndServe(":3000", nil)
}

Run the main.go using the command

go run main.go

So, if we now go to the browser and open http://localhost:3000/ we can see the "Hello, World!" text which we are returning.

In this example, the handler function is mapper to the root path which is "/". Likewise, we can create multiple routes and register them to their corresponding handlers.

All done! 🎉

That’s it for now guys. Will meet you guys again with another interesting topic.

GO for GO

Heertheeswaran V — Thu, 17 Oct 2019 05:10:44 +0000

I started to learn Go a few weeks ago as a hobby. In this article series, I will document everything I learn.

What is GO?

As all probably know, Go is a general-purpose language developed by Google and has a wide range of applications. Go takes us back to the syntax of C++.

The most important feature of Go is its concurrency. It allows multiple processes to run simultaneously and effectively thanks to its garbage collector, goroutines (a lightweight thread managed by Go for efficient concurrency) and channels. And of course, GO is an open-source language.

So, let’s now dive into the workspace setup.

Setting Up Workspace:

The go program is made up of packages. The package acts as an entry point for an application. Before you start crushing it on Go, we need to set up a workspace. A normal Go workspace looks like this:

bin/
    hello                          # command executable
    outyet                         # command executable
src/
    github.com/golang/example/
        .git/                      # Git repository metadata
    hello/
        hello.go               # command source
    outyet/
        main.go                # command source
        main_test.go           # test source
    stringutil/
        reverse.go             # package source
        reverse_test.go        # test source
    golang.org/x/image/
        .git/                      # Git repository metadata
    bmp/
        reader.go              # package source
        writer.go              # package source

A typical workspace contains many source repositories containing many packages and commands. Most Go programmers keep all their Go source code and dependencies in a single workspace.

The tree above shows a workspace containing two repositories (example and image). The example repository contains two commands (hello and outyet) and one library (stringutil). The image repository contains the bmp package and several others.

The GOPATH environment variable specifies the location of your workspace. Set the GOPATH variable to your desired directory by using the command below:

export GOPATH = <desired directory>

A simple Go program:

We can now dive into writing a simple Go program. I have set my Go workspace as shown below. My GOPATH variable is set to my “go_workspace”.

I have created the package folder “simple_program” in the src folder under the corresponding repository. Let’s now write a simple go program in “simple_program/simple_program.go”

package main

import "fmt"

func main() {
    fmt.Println("This is a simple go program.")
}

Executing a GO program:

As said earlier, package main acts as the entry point. There are two ways you can run a go program

Build as an executable and run. To build the Go program as an executable in the program directory run the command - go build file_name.go or go install file_name.go
- The Go build command creates an executable file in the current directory which can be executed as below:
- The Go install command - created an executable file in the bin folder of the GOPATH and this bin can be added to our environment PATH and can be used anywhere.
The simple way to run is by using the command - go run file_name.go.

That’s it for now guys. Will meet you guys again with another interesting topic.