Ім'я файлу: Git-Gitflow.pptx
Розширення: pptx
Розмір: 761кб.
Дата: 04.07.2022
скачати
Пов'язані файли:
Славич Захар.pptx
14-16.docx
педіатрія.docx
Аристотель.docx
ФІЗИКА 3.docx
2кур.docx
ТЕХНОЛОГЫЧНЫ КАРТИ.docx
99763.ppt

Git for Version Control

Why Git?

  • Git :most commonly used software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development.
  • Git has many advantages over earlier systems such as CVS and Subversion

Subversion

Git

Adding a file to git repository

  • $git checkout feature
  • $ git status
  • $ git add filename or . – add all or git commit –am “message”
  • $ git status
  • $ git commit -m “Implemented …“
  • $ git push feature

Adding Multimpule files…

Git flow


Gitflow is great for projects that have a planned release cycle. This model assumes no additional concepts beyond those described for the Feature Branch Workflow model. Instead, it assigns specific roles to different branches and determines how and when they should interact. In addition to feature branches, it uses separate branches for preparing, maintaining, and writing a release. Of course, you also need to make good use of all the benefits of the Feature Branch Workflow: pull requests, isolation for changes, and effective collaboration within the team.

How it works?


Master and Develop branches instead of using a single master branch, this model uses two branches to record the history of a project. The master branch holds the official release history, while the develop branch serves as an integration branch for new features. Also, it is convenient to tag all commits in the master branch with a version number. The first step is to create a develop branch from the master branch. The easiest way to do this is for a single developer to create an empty branch locally and push it to the central repository.

This branch will contain the entire history of the project, while master contains a partial history. The rest of the developers must now clone the central repository and create a tracking branch for the develop branch.

Feature branches


Each new feature should be developed on a separate branch that can be pushed to a central repository for backup/team collaboration. Feature branches are created not on the basis of master, but on the basis of develop. When work on a new feature is completed, it is merged back into develop. New code should not be sent directly to master.

Release branches


When enough new code has already been merged into the develop branch for a release a release branch is created from the develop branch. The creation of this branch means the beginning of the next release cycle, during which new functionality is no longer added, but only bugs are debugged, documentation is created, and other release-related tasks are solved. When everything is ready, the release branch is merged into master and the version tag is assigned to it. In addition, it must also be merged back into the develop branch, which may have added changes since the release branch since the creation of the release branch.

Using a separate release branch allows one team to work on the current release while another team is already working on features for the next release. It also allows you to delineate development milestones.

Creating release branches is another simple branching operation. Like feature branches, release branches are based on the develop branch.

When a release is ready to ship, it is merged into master and develop, and the release branch is deleted. It's important to merge it back into develop because critical updates may be added to the release branch and they need to be available for new features. If your team is focusing on code reviews, this is the perfect moment for a pull request.

Hotfix branches


Hotfix branches are used to quickly make fixes to the production version of the code. Hotfix branches are very similar to release and feature branches, except they are from master rather than from develop. This is the only branch that must be created directly from master. Once the fix is ​​complete, the hotfix branch should be merged into both master and develop (or the current release branch), and master should be tagged with the updated version number.

Having a dedicated bug fix branch allows the team to resolve issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of hotfix branches as special release branches that work directly with master.

JWT

JSON Web Token (JWT) – JSON object. It is considered one of the safest ways to transfer information between two parties. To create it, you need to define a header (header) with general information on the token, payload data (payload), such as user id, role, etc. and signatures. Suppose we want to register on the site. In our case, there are three members - the user, the application server, and the authentication server. The authentication server will provide the user with a token with which he can later interact with the application.
First, the user logs into the authentication server using an authentication key (this can be a login / password pair, or a Facebook key, or a Google key, or a key from another account).

The authentication server creates a JWT and sends its settings. When a user sends a request to an API application, it releases the JWT it received earlier.

When a user submits an API request, the application can check against the submitted JWT request to see if the user is who they claim to be. In this server, the application framework is configured so that it is possible to verify that the incoming JWT is exactly what the authentication server was (the verification process will be described later in more detail).

The application uses the JWT to authenticate the user to the specified path.

Structure JWT

  • Step 1. Create a Header
  • The JWT header contains information about how the JWT signature should be calculated. The header is also a JSON object that looks like this:

    The typ field doesn't tell us anything new, only that it's a JSON Web Token. More interesting here is the alg field, which defines the hashing algorithm. It will be used when creating the signature. HS256 is nothing but HMAC-SHA256 and only needs one secret key to compute it (more on that in step 3). Another RS256 algorithm can also be used - unlike the previous one, it is asymmetric and creates two keys: public and private. The private key creates a signature, while the public key only verifies the authenticity of the signature, so we don't have to worry about its security.

Step 2. Create PAYLOAD

  • Step 2. Create PAYLOAD
  • Payload is the payload that is stored inside the JWT. This data is also called JWT-claims. In the example we are considering, the authentication server creates a JWT with information about the user id - userId.

    We put only one claim in payload. You can submit as many entries as you like. There is a list of standard claims for JWT payload - here are some of them:

  • iss (issuer) - Identifies the application from which the token is being sent.
  • sub (subject) - defines the subject of the token.
  • exp (expiration time) — token lifetime.
  • But it is worth remembering that the more information is transmitted, the larger the JWT itself will end up. This is usually not a problem, but it can still negatively affect performance and cause delays in communication with the server.

Step 3. Create SIGNATURE

  • Step 3. Create SIGNATURE
  • The base64url algorithm encodes the header and payload created in steps 1 and 2. The algorithm connects the encoded strings through a dot. Then the resulting string is hashed by the algorithm specified in the header based on our secret key.

Step 4. Now let's combine all three JWT components together.

Now that we have all three pieces, we can create our JWT. It's quite simple, we connect all the received elements into a string through a dot.

Types of tokens

  • Access tokens are usually short-lived JWTs signed by the server. They are included in every HTTP request made by the client to the server. Tokens are used to authorize requests.
  • Refresh tokens are typically long-lived tokens stored in a database and used to obtain a new access token when the previous token expires.

Refresh Tokens

Understanding how client-side refresh token works

  • First of all, we need to know how the refresh token strategy will work in our SPA application.
  • After the user logs into our application, our API will return an object containing the AccessTokenRefreshToken, and UserInfo.
  • AccessToken and RefreshToken will be saved in LocalStorage and at each request for a new endpoint with access protection only for authenticated users, for example, the user data display route, AccessToken will be added in the header of this request.
  • Using the Axios library to perform these requests, we have a method called interceptor. This method allows us to intercept our request or response before our data is processed, making it possible to check if our AccessToken has expired and sent a new request to gain access to our request route that we want to access.

Storage of tokens

There are 2 common ways to store tokens on the client: browser local storage and cookies. There is a lot of debate about which way is better. Most people lean towards cookies because of their better security.

Local Storage

Cookies

Advantages

Disadvantages

Advantages

Disadvantages

Very well organized work.

An attacker can run his JS code on your site and get access to the token in localStorage.

Not hackable.

The size of cookies is limited to 4kb, it will not be possible to use large tokens.

It is convenient to work with APIs that require you to place an access token in the request header.

Cookies are automatically sent in every HTTP request to the server.

Not all projects can transfer cookies to their api server, and it is possible that some api will require the token to be placed in the Authorization header, and in this case we will not be able to store the token in cookies.

скачати

© Усі права захищені
написати до нас