DEV Community: Saranya Jena

Understanding User Management and Authentication in LitmusChaos

Saranya Jena — Mon, 23 Aug 2021 16:05:04 +0000

In this post, I will be explaining how user management and authentication are done in LitmusChaos. LitmusChaos is a Cross-Cloud Chaos Orchestration framework for practicing chaos engineering in cloud-native environments.

LitmusChaos 2.0 is out now!🚀

LitmusChaos 2.0 provides a new way of chaos engineering performed by the users. LitmusChaos itself is composed of microservices. And we made sure that adding the features for 2.0 seamlessly integrates the additional microservices in conjunction with the existing one. It is completely backward compatible. No features are deprecated.

Highlights:

All features of Litmus 1.x
Addition of Chaos Workflow creation
User Management & Teaming
Introduction of ChaosCenter (The central chaos management center)
Monitoring and Observability
Resilience Score Calculation
Manage Workflows using GitOps, Custom Image Registry

User Roles and Accessibility

First of all let me explain the different user level roles and their privileges. LitmusChaos also has project-level roles which come under the teaming section.

Admin: The admin user is created by default on the initial portal setup and can log into the portal using the credentials admin/litmus once the server pods are up and running. The admin can access every feature with exclusive access to the User-management feature for user creation and management. Admin users can also view the overall usage statistics of the portal.
Non-Admins: The non-admin users, created by the admin, have access to all the features except User-management and Usage statistics.

Features

User-management

Admin can access the following features through the User management section:

Create a User: Admin can create a user by assigning a unique username and password and other optional details like name email-id.
View Users list: Once the user is created, it will be listed in the table along with other details such as current status(active or deactivated), name, username, email-id, date, and time of the user creation.
Activate/Deactivate users: Admin can toggle the current status of the user. Once a particular user is deactivated he/she won't be able to access any APIs of the LitmusChaos but all the previous data will be stored, which can be accessed back once the user gets reactivated.
Edit profile: Here, Admin can reset the password of other users.

Authentication and Getting Started

Once a user is created, the user will be able to login into the portal with non-admin privileges. In case a user forgets the credentials, he/she can contact the portal admin to reset the credentials.
On successful authentication, the user will be redirected to /getStarted route. For the initial login, users will be asked to change the password and use the updated password for subsequent logins. One can also skip the option to change the password. Users can update their password anytime through the My Account section. In either case, a default project will be created for you under which you can do your chaos testing!

Here's a short GIF explaining all the basic features of User-management:

Some noteworthy points

I have noticed, people are often confused between the types of roles. There are two layers of privilege levels:

Portal Level: This is the first layer of privilege levels where user roles are assigned during user creation. As of now, one who installs the LitmusChaos and logs in with admin/litmus credentials is assigned the role admin, and all other users created by admin are assigned the role user.
Project Level: This is the second layer of the privilege level, where roles are assigned to the project members while sending an invitation. If you want to know more about Projects and Teaming, you can find it here

Conclusion

That's all, folks. Thank you for reading it till the end. I hope you had a productive time learning about LitmusChaos, and we hope you are as excited as we are about the upcoming features/additions!

Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?

Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes: https://slack.litmuschaos.io (#litmus channel on the Kubernetes workspace)

Check out the Litmus Chaos GitHub repo and do share your feedback: https://github.com/litmuschaos/litmus/issues
Submit a pull request if you identify any necessary changes.
Show your ❤️ with a ⭐ on our Github. To learn more about Litmus, check out the Litmus documentation. Cheers✌🏼

Introducing Teaming in LitmusChaos to ease your Chaos Engineering experience

Saranya Jena — Thu, 20 May 2021 10:27:34 +0000

This blog covers everything you need to know about the teaming feature provided by LitmusChaos for your Chaos Engineering needs.

Litmus is a Cross-Cloud Chaos Orchestration framework for practicing chaos engineering in cloud-native environments. Litmus provides a chaos operator, a large set of chaos experiments on its hub, detailed documentation, and a friendly community.

Why teaming?

"Teamwork is the ability to work together towards a common vision. The ability to direct individual accomplishments towards organizational objectives. It is the fuel that allows common people to attain uncommon results."

-Andrew Carnegie

The quote from Andrew Carnegie probably answers the questions.

You might be wondering how this feature alters your Chaos Engineering experience? Why does LitmusChaos emphasize teaming?
Imagine being a firefighter and dealing with the fire alone. You don’t want to be alone in the chaos you created.

If you are working on a chaos engineering project and want to share the details/analytics with someone, you don’t have to export the data every time and share it with everyone individually, instead, Litmus provides users with a teaming feature that allows users to invite other members to their project and participate in it so that they can get the real-time update about the project.

Litmus Chaos 2.0 Advanced Beta Out Now!🚀

LitmusChaos 2.0 Advanced Beta provides a whole new way to perform chaos engineering, apprehending some high-level features. It comes with a lot of new and enhanced features such as GitOps, for Chaos Engineering, Workflow Sequence Editing, Visualization of workflows, Chaos Interleaved dashboards, and many more. You can find a detailed list on the release page. It also includes a brand new UI for teaming along with some additional features. We’ll be exploring all of its features including the different kinds of roles and their access levels. A member of a project can schedule, modify workflows and view the analytics based on the member’s role in the project.
We’ll start with explaining the different roles of a user in a team briefly. There are three project roles in Litmus:

Owner: One who created the project and owns it. Only the owner has permission to manage(invite or remove) the members in his/her project. The owner can schedule workflows, update workflows, delete workflows and view the analytics.
Editor: Members invited with editor role can do everything an owner can except for managing the members in the project
Viewer: Members having a viewer role can only view the analytics related to the workflows.

Highlights

Now let's take a deeper dive into the features, what all we can achieve with teaming. It comes with the following features:
Choose role and send the invitation: With this, you can select as many users you want, choose their roles individually and send the invitation at once! Once it is done successfully you can see the status of your invitation ( whether it is pending/accepted/declined or exited) along with all other necessary details in the Invited tab.
Edit invitation: Now if you had a change of mind and you wanted to change the role, we got you! Just go to the invited tab, change the role, and hit the Resend button. You can also cancel the invitation by just clicking on the Bin icon.
Respond to the invitation: Once the invitation is received, the user can take a look at details including the sender's name, role, and project name, then decide whether to accept or decline the invitation.
Leave or View Project: Once you are done with the project and don’t want to be a part of it anymore, you can go to the Active tab, here you can either switch to a project you want to view or can leave it by just clicking on the Leave Project button!
Remove a Member: If you are the project owner, you can also remove any member!

Once you respond to the invitation or leave it afterwards, the status will automatically get updated in the sender's account. Here's a short GIF explaining all the basic features of teaming.

Conclusion

That's all folks! Thank you for sticking around. We hope you had a productive time reading about Litmus and its teaming feature.

This blog is also contributed by Sarthak Jain.

Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you? Want to chat with us, we are available in Kubernetes slack (#litmus channel on the Kubernetes workspace).

litmuschaos / litmus

Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q

LitmusChaos

Open Source Chaos Engineering Platform

Read this in other languages.

🇰🇷 🇨🇳 🇧🇷 🇮🇳

Overview

LitmusChaos is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. Developers & SREs can practice Chaos Engineering with LitmusChaos as it is easy to use, based on modern Chaos Engineering principles & community collaborated. It is 100% open source & a CNCF project.

LitmusChaos takes a cloud-native approach to create, manage and monitor chaos. The platform itself runs as a set of microservices and uses Kubernetes custom resources (CRs) to define the chaos intent, as well as the steady state hypothesis.

At a high-level, Litmus comprises of:

Chaos Control Plane: A centralized chaos management tool called chaos-center, which helps construct, schedule and visualize Litmus chaos workflows
Chaos Execution Plane Services: Made up of a…

View on GitHub

Do check out the LitmusChaos Github repo and share your valuable feedback. Feel free to submit a pull request if you notice any necessary changes.😇

How to use React hooks in Apollo Client for GraphQL

Saranya Jena — Tue, 22 Sep 2020 07:33:03 +0000

Hello World! In this blog, I am going to discuss how we can use React hooks with Apollo to connect to GraphQL API in different scenarios. Assuming that you have a basic understanding of the same, I will be explaining how GraphQL data can be shared with the UI using React hooks by giving a few examples that we are already using in our ongoing project, the Litmus Portal.

What is GraphQL?

Before going forward, let me give a very brief overview of GraphQL and what all things we are going to discuss. So GraphQL is a query language for APIs that is developed by Facebook. It is an efficient alternative to REST because of its features such as:

With GraphQL there's no over fetching or under fetching of data, unlike REST.
Strongly typed graphQL schema which can be written in GraphQL Schema Definition Language (SDL) helps you validate your API requests during its compile time.
With the development of various GraphQL libraries (Apollo, Relay, etc) you are getting a lot of features such as caching, realtime data, etc.
It provides a large and amazing community! You can always get your queries answered whenever stuck.

This was just a basic introduction to GraphQL, but I recommend you to visit the site to gain deeper insights of the same.

What we'll do?

I will be mainly focussing on the front-end side, where I am gonna explain the two very useful react hooks useQuery and useMutation, how are we using these in our project for GraphQL operations along with the code.

Wait...what are GraphQL operations?

GraphQL provides various types of operations such as Query, Mutation, and Subscription which act as the entry points for the requests sent by the client. In this blog, I'll be discussing the first two types i.e. Query and Mutation.

Query: useQuery hook is used to fetch the data from the server and attach it to the UI. To run a query you need to call this hook by passing the query string, it returns an object from Apollo client containing data, error, loading properties which change their values after execution. The hook is called when the component renders and the above properties can be used conditionally to render the UI.

Basic syntax:

const { loading, error, data } = useQuery<Type1, Type2>(
    QUERY_STRING,
    { variables: <variable>,
onCompleted:()=>{console.log("query successful",data);}
,
onError:(error)=>{console.error(error);},
});

data : The required data we are getting after the query is successful.
loading : It is a boolean value, if true, it means the query is still in flight. After it is successful the value of loading changes to false.
error : It stores the error if occurred while querying.

Mutation: useMutation hook is used to send updates to the GraphQL server as a result of which data can be updated in the back-end. It is somewhat similar to useQuery in terms of syntax with some minor differences. To execute a mutation, you need to pass the mutation string to the hook. This hook returns a tuple containing a mutate function which can be called whenever its execution is required and an object having certain fields that represent the current status of mutation's execution.

Basic syntax:

 const [mutateFunction,{ error,loading}] = useMutation<Type>(MUTATION_STRING, {
    onCompleted: () => {
    console.log("details updated")
    },
    onError: (error) => {
    onError:(error)=>console.error(error);
    },
    refetchQueries: [{ query: QUERY_STRING, variables: <variable>],
  });

mutateFunction : It is the mutate function which can be called anytime to run the mutation.
The second parameter is the object representing the mutation's execution status such as error , loading which have been explained above.

In both examples, I have added options to the hooks:

onCompleted : It is a callback executed after a successful query/mutation.
onError : Callback executed in case of an occurrence of error.
refetchQueries : It takes an array or function which is used to specify a list of queries that need to be refetched after the mutation is successful.

Some of the good practices you can follow:

Type the data you are sending or receiving during the requests wherever it is required. It enhances readability and understandability.
As a beginner we often tend to store the data we received from the requests in local states which is not required. Apollo Client provides an in-memory cache in which it stores the data that helps the client to respond to future queries for the same data without sending unnecessary requests. So instead of storing it in local states we can directly access and use it without making repeated requests.

Now I'll be explaining some examples that we have used in our ongoing project, the Litmus Portal.

LitmusChaos

LitmusChaos is an open-source toolset to practice chaos engineering in cloud-native systems. It comes up with a large set of chaos experiments that are hosted on the hub. For further details, you can check out our github repo. Litmus Portal provides a console and UI experience for managing, monitoring, and events around chaos workflows. It is being developed using React and TypeScript for the front-end and Golang for the back-end.

Examples

Without any further delay, let's get started!!

Since the examples I am going to explain are a part of a project, I have excluded some parts of the logic which are not relevant to the blog. You can find the complete code here.

Query

Schema

export const GET_USER = gql`
  query getUser($username: String!) {
    getUser(username: $username) {
      username
      email
      id
      name
      projects {
        members {
          user_id
          user_name
          role
          invitation
          name
          email
          joined_at
        }
        name
        id
      }
      company_name
      updated_at
      created_at
      removed_at
      is_email_verified
      state
      role
    }
  }
`;

export const ALL_USERS = gql`
  query allUsers {
    users {
      id
      name
      username
      email
    }
  }
`;

The GET_USER query string returns the complete details of a user whose username is passed as a variable.
The ALL_USERS query string returns a list of all users who are present along with their details including id, name, username, and email.

useQuery

const { data: dataB } = useQuery<CurrentUserDetails, CurrentUserDedtailsVars>(
    GET_USER,
    { variables: { username: userData.username } }
  );

 const { data: dataA } = useQuery(ALL_USERS, {
    skip: !dataB,
    onCompleted: () => {

    //consoles the list of all users present
    console.log(dataA.users);
    },
    onError: (error) => {
    //in case of error, it prints the error message in the console
    console.error(error.message)
  });

In the above example, I have two queries:

GET_USER : I am sending the username as variable to get all the details associated with that username. The received data can be accessed through dataB. CurrentUserDedtailsVars is the type of data I am sending i.e. the username and CurrentUserDetails is the type of data I am receiving on a successful query. These types are stored in a separate file:

export interface Member {
  user_id: string;
  user_name: string;
  role: string;
  invitation: string;
  name: string;
  email: string;
  joined_at: string;
}

export interface Project {
  members: Member[];
  name: string;
  id: string;
}

export interface UserDetails {
  username: string;
  projects: Project[];
  name: string;
  email: string;
  id: string;
  company_name: string;
  updated_at: string;
  created_at: string;
  removed_at: string;
  is_email_verified: string;
  state: string;
  role: string;
}

export interface CurrentUserDetails {
  getUser: UserDetails;
}

export interface CurrentUserDedtailsVars {
  username: string;
}

ALL_USERS : This query is for fetching the list of all the users which can be accessed through dataA.

skip : This is a boolean value, if true, the query will be skipped. In the above logic if dataB is empty i.e. unless and until GET_USER query is successful ALL_USERS query will be skipped. Once dataA gets populated then the second query is executed. This option is useful in the cases where you need to execute the queries in specific order.

Mutation

Schema

export const SEND_INVITE = gql`
  mutation sendInvite($member: MemberInput!) {
    sendInvitation(member: $member) {
      user_id
      user_name
      role
      invitation
    }
  }
`;

The SEND_INVITE mutation string is used to send an invitation to a user for a selected project. Once the user accepts the invitation he/she becomes a member of that project too. As MemberInput we need to send the data which includes the id of the project, the username of the user whom we are going to send the invitation, the role of user in the project name Viewer or Editor.

useMutation

 // mutation to send invitation to selected users
  const [SendInvite, { error: errorB, loading: loadingB }] = useMutation<
    MemberInviteNew
  >(SEND_INVITE, {
    refetchQueries: [{ query: GET_USER, variables: { username } }],
  });

In the above mutation, once the invitation is sent(mutation is successful), the GET_USER query is refetched to update the data.

MemberInviteNew is the type of data I am sending as variables to mutation string. The interface is defined as follows:

export interface MemberInviteNew {
  member: {
    project_id: string;
    user_name: string;
    role: string;
  };
}

SendInvite is the mutate function which can be called whenever you want to execute the mutation.

 SendInvite({
   variables: {
       member: {
             project_id: "1234abc",
             user_name: "john_doe",
             role: "Editor",
               },
              },
            })

Conclusion

So these were some of the examples of GraphQL mutation and query. I hope I was able to explain these concepts well, but if you still have some queries or feedback feel free to reach out to me. Since the LitmusChaos project is completely open-source, feel free to contribute in any way possible. Visit the GitHub repo and become one out of the many stargazers.

litmuschaos / litmus

Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q

LitmusChaos

Open Source Chaos Engineering Platform

Read this in other languages.

🇰🇷 🇨🇳 🇧🇷 🇮🇳

Overview

At a high-level, Litmus comprises of:

Chaos Control Plane: A centralized chaos management tool called chaos-center, which helps construct, schedule and visualize Litmus chaos workflows
Chaos Execution Plane Services: Made up of a…

View on GitHub

Last but not the least, with the upcoming Hacktober Fest, there are many issues for all levels such as good-first issues, front-end issues, complex issues, etc. So even if you are a beginner you can always submit a PR and start contributing to open source. Grab your chance to win a lot of Litmus swags and goodies upon a successful merge. So do not forget to visit the Litmus site and join our community(#litmus channel on the Kubernetes Slack).😇