Edison  Stark

Edison Stark

1598982960

Access Control in Nebula Graph: Design, Code, and Operations

Access Control List (ACL) is not alien to database users and it is a significant part of data security. Like other database vendors, Nebula Graph takes data security seriously and now supports role-based access control.

In this article, we will detail user management with roles and privileges of Nebula Graph.

The Authentication Workflow

Nebula Graph is composed of three parts: the query engine, the storage layer and the meta service. The console, API and the web service are collectively referred to as Client API. See the figure below:

The account and role data will be stored in the meta engine. When query engine is started, the meta client through which the query engine communicates with the meta service will be initialized.

When users connect to query engine through the client API, the query engine will check the user information on the meta engine via the meta client, determining the existence of the requesting account and the correctness of the password. Once the verification is passed, the connection succeeds. Users can then perform data operations in this session.

Once a query is received, the query engine will parse it, which involves identifying the command type and verifying user’s authority based on the operation and the user’s role. If the authority is invalid, the command will be blocked in the query engine and an error is returned to the client API. In the entire permission check process, Nebula Graph caches the meta data. We will detail this in the next chapter.

The Access Control Logic

In general, access control is realized through roles and privileges granted to each role. However, in Nebula Graph, permissions are also granted at graph space level.

Nebula Graph supports creating multiple graph spaces in the database. The schema and graph data are managed in each space independently and the spaces are psychically isolated from each other. In addition, Nebula Graph also provides a set of advanced commands for managing the cluster globally.

Therefore, the ACL of Nebula Graph will be managed in three dimensions: graph spacesroles and operations.

Role Types

Nebula Graph provides five built-in roles: GOD, ADMIN, DBA, USER and GUEST. These roles have covered all the scenarios in data security. An account can have different roles in different spaces. But it can only have one role in the same space.

Descriptions for the roles:

  • GOD
  • The initial root user similar to the Root in Linux.
  • Has the highest management access to the cluster.
  • When a cluster is initialized, a GOD account named root is created by default.
  • ADMIN
  • Advanced administration at the graph space level.
  • Full management access to a specific graph space.
  • No management access to the cluster.
  • DBA
  • Database administration.
  • Access to its authorized graph space. For example, alter or query the schema and data.
  • Not able to assign roles to users compared to ADMIN.
  • USER
  • Read/write access to the graph data limited to its authorized space.
  • Read-only access to the schema limited to its authorized space.
  • GUEST
  • Read-only access to both the schema and graph data limited to its authorized space.

#database #graph database #access control #nebula graph #access control logic

What is GEEK

Buddha Community

Access Control in Nebula Graph: Design, Code, and Operations
Edison  Stark

Edison Stark

1598982960

Access Control in Nebula Graph: Design, Code, and Operations

Access Control List (ACL) is not alien to database users and it is a significant part of data security. Like other database vendors, Nebula Graph takes data security seriously and now supports role-based access control.

In this article, we will detail user management with roles and privileges of Nebula Graph.

The Authentication Workflow

Nebula Graph is composed of three parts: the query engine, the storage layer and the meta service. The console, API and the web service are collectively referred to as Client API. See the figure below:

The account and role data will be stored in the meta engine. When query engine is started, the meta client through which the query engine communicates with the meta service will be initialized.

When users connect to query engine through the client API, the query engine will check the user information on the meta engine via the meta client, determining the existence of the requesting account and the correctness of the password. Once the verification is passed, the connection succeeds. Users can then perform data operations in this session.

Once a query is received, the query engine will parse it, which involves identifying the command type and verifying user’s authority based on the operation and the user’s role. If the authority is invalid, the command will be blocked in the query engine and an error is returned to the client API. In the entire permission check process, Nebula Graph caches the meta data. We will detail this in the next chapter.

The Access Control Logic

In general, access control is realized through roles and privileges granted to each role. However, in Nebula Graph, permissions are also granted at graph space level.

Nebula Graph supports creating multiple graph spaces in the database. The schema and graph data are managed in each space independently and the spaces are psychically isolated from each other. In addition, Nebula Graph also provides a set of advanced commands for managing the cluster globally.

Therefore, the ACL of Nebula Graph will be managed in three dimensions: graph spacesroles and operations.

Role Types

Nebula Graph provides five built-in roles: GOD, ADMIN, DBA, USER and GUEST. These roles have covered all the scenarios in data security. An account can have different roles in different spaces. But it can only have one role in the same space.

Descriptions for the roles:

  • GOD
  • The initial root user similar to the Root in Linux.
  • Has the highest management access to the cluster.
  • When a cluster is initialized, a GOD account named root is created by default.
  • ADMIN
  • Advanced administration at the graph space level.
  • Full management access to a specific graph space.
  • No management access to the cluster.
  • DBA
  • Database administration.
  • Access to its authorized graph space. For example, alter or query the schema and data.
  • Not able to assign roles to users compared to ADMIN.
  • USER
  • Read/write access to the graph data limited to its authorized space.
  • Read-only access to the schema limited to its authorized space.
  • GUEST
  • Read-only access to both the schema and graph data limited to its authorized space.

#database #graph database #access control #nebula graph #access control logic

Landscapes Website Design | Nature Landscapes Website Designer

Most landscapers think of their website as an online brochure. In reality of consumers have admitted to judging a company’s credibility based on their web design, making your website a virtual sales rep capable of generating massive amounts of leads and sales. If your website isn’t actively increasing leads and new landscaping contracts, it may be time for a redesign.

DataIT Solutions specializes in landscape website designing that are not only beautiful but also rank well in search engine results and convert your visitors into customers. We’ve specialized in the landscaping industry for over 10 years, and we look at your business from an owner’s perspective.

Why use our Landscapes for your landscape design?

  • Superior experience
  • Friendly personal service
  • Choice of design layout
  • Budget sensitive designs
  • Impartial product choice and advice
  • Planting and lighting designs

Want to talk about your website?
If you are a gardener or have a gardening company please do not hesitate to contact us for a quote.
Need help with your website?
Get in touch

#nature landscapes website design #landscapes website design #website design #website designing #website designer #designer

Tyrique  Littel

Tyrique Littel

1604008800

Static Code Analysis: What It Is? How to Use It?

Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.

Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.

“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”

  • J. Robert Oppenheimer

Outline

We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.

We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.

Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use ast module, and wide adoption of the language itself.

How does it all work?

Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:

static analysis workflow

As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:

Scanning

The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.

A token might consist of either a single character, like (, or literals (like integers, strings, e.g., 7Bob, etc.), or reserved keywords of that language (e.g, def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.

Python provides the tokenize module in its standard library to let you play around with tokens:

Python

1

import io

2

import tokenize

3

4

code = b"color = input('Enter your favourite color: ')"

5

6

for token in tokenize.tokenize(io.BytesIO(code).readline):

7

    print(token)

Python

1

TokenInfo(type=62 (ENCODING),  string='utf-8')

2

TokenInfo(type=1  (NAME),      string='color')

3

TokenInfo(type=54 (OP),        string='=')

4

TokenInfo(type=1  (NAME),      string='input')

5

TokenInfo(type=54 (OP),        string='(')

6

TokenInfo(type=3  (STRING),    string="'Enter your favourite color: '")

7

TokenInfo(type=54 (OP),        string=')')

8

TokenInfo(type=4  (NEWLINE),   string='')

9

TokenInfo(type=0  (ENDMARKER), string='')

(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)

#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer

Juned Ghanchi

1621315250

Designing Mobile Apps using the latest UI Design Principles

The mobile technology world is growing at the speed of light, and the apps have become an integral part of our daily life. We can now see an influx of technology with tools that can help create mobile apps. All of them are becoming more accessible and hence people are getting on their first app making journeys. Since the mobile app industry is getting bigger and better than ever, businesses from all corners of the world are trying to develop mobile apps for their operations and marketing. Designing a mobile app for businesses is the first step, though. Company owners are in charge of the basic look and feel of the designed product. With a brilliant mobile app design, one can establish a relationship between app and user very well.

Read Blog Here: https://www.indianappdevelopers.com/blog/designing-mobile-apps-using-latest-ui-design-principles/

#designing mobile apps #ui design principles #mobile ui design #mobile app design #ui design #app design

Loma  Baumbach

Loma Baumbach

1596821940

Nebula Graph Source Code Explained via a Sample Graph Query

When I saw the Nebula Graph code repository for the first time, I was so shocked by its huge size that I didn’t know how to dig into the source code. Then I worked up the nerve. After reading the code and running the use cases over and over, I finally gained some experience worth sharing with you, hoping that all my experience could push you to give Nebula Graph source code a shot to know more about the graph DBMS, to improve your graph database knowledge, and to fix some bugs that are not so complicated of this repository.

In this article, I took the SHOW SPACES statement as an example to show you how Nebula Graph processes an nGQL statement after it was input on the client side. GDB, the GNU Project debugger, was used to trace the execution.

Additionally, some open-source libraries are used in Nebula Graph. For more information, see the Libraries section.

Architecture of Nebula Graph

A complete Nebula Graph DBMS contains three services: Query Service, Storage Service, and Meta Service. Each service has its own executable binary files.

Query Service is responsible for these tasks:

  • Managing connection to the client
  • Parsing an nGQL statement input from a client into an AST (Abstract Syntax Tree) and then parsing the AST to an execution plan
  • Optimizing the execution plan
  • Executing queries with the optimized execution plan

Storage Service is responsible for distributed data store.

Meta Service is responsible for these tasks:

  • Operating CRUD on graph schema objects
  • Managing the cluster
  • Performing user authentication

In this case, I used Query Service as an example to show you some experience.

Source Code Directory Hierarchy

When we get the source packages and have them unzipped, we should do a check of the source code directory hierarchy. Each package has its own functions. Here is how the src directory looks like.

Shell

1

|--src

2

    |--client // Provides the code for the client

3

    |--common // Provides some common basic components

4

    |--console

5

    |--daemons

6

    |--dataman

7

    |--graph // Contains most codes of Query Service

8

    |--interface // Contains some communication interfaces for meta, storage, and query services

9

    |--jni

10

    |--kvstore

11

    |--meta // Relates to meta service information 

12

    |--parser // Contains modules for lexical parsing (Lexer) and semantic analysis 

13

    |--storage // Contains codes about the storage layer

14

    |--tools

15

    |--webservice

#database #tutorial #c++ #graph database #source code #nebula graph