You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
🏠
Working from home
Elvin Asadov
aemloviji
🏠
Working from home
Primary Skill is C♯
https://www.linkedin.com/in/elvin-asadov
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The authentication flows, dictate the process on how a client application can receive an access token from the authorization server. Each flow is appropriate for different scenarios, not all flows are appropriate for all kinds of applications. There are two types of redirect flows and two types of credential exchange type of flows.
Redirect flows
Implicit grant flow. This is one of the most popular approaches, the resource owner is redirected to the authorization server and logins there. After a successful login, user is redirected back to the client application, where they get their access token.
Authorization code flow. This is similar approach to the above, with one twist. Instead of getting an access token when redirected back to the website, we simply get an authorization code, which can be used to trade for an access token. This mechanism adds an extra layer of security, mitigating MIM attacks.
NoSQL (non-relational) databases are ideal for distributed network applications. Unlike their vertically scalable SQL (relational) counterparts, NoSQL databases are horizontally scalable and distributed by design—they can rapidly scale across a growing network consisting of multiple interconnected nodes.
The ‘CAP’ in the CAP theorem, explained
Let’s take a detailed look at the three distributed system characteristics to which the CAP theorem refers.
Consistency
Consistency means that all clients see the same data at the same time, no matter which node they connect to. For this to happen, whenever data is written to one node, it must be instantly forwarded or replicated to all the other nodes in the system before the write is deemed ‘successful.’
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FROM — specifies the base (parent) image. LABEL —provides metadata. Good place to include maintainer info. ENV — sets a persistent environment variable. RUN —runs a command and creates an image layer. Can be used to install packages into containers or run specific commands(i.e mkdir and etc.). COPY — copies files and directories to the container. ADD — copies files and directories to the container. Can upack local .tar files. CMD — provides a command and arguments for an executing container. Parameters can be overridden. There can be only one CMD. WORKDIR — sets the working directory for the instructions that follow. ARG — defines a variable to pass to Docker at build-time. ENTRYPOINT — provides command and arguments for an executing container. Arguments persist.\
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. A volume allows data to persist, even when a container is deleted. Volumes can be used to share data between the host and the container(s).
By mounting a volume you can achive to
Pull data from a container.
Push data to a container.
Share data between containers.
Please note that, arguments prefixed with @(at) in below commands must be replaced with actual values.