TURK GUZELI – BOOK YOUR BEAUTY
TURK GUZELI – BOOK YOUR BEAUTY SESSION ONLINE IN TURKEY

APP Available only in Turkey .
Development : Naro Dev








No products in the cart.
In web applications, you try to decide when to use either JSON Web Tokens (JWTs) or sessions (cookies) for authentication. When you browse the web you use HTTP, which is a stateless protocol. So, the only way to remember the states of your application is using either sessions or tokens.
Fetch API has become the standard for web API requests for a while now and it is supported in almost any modern browsers nowadays. Let’s use Fetch API and implement it for the web
Previously, there are many existing solutions for handling API requests for the web, ex. jQuery Ajax, request (node), axios (node) … why there needs another?
Fetch API is the standard API being supported native in most of today web browsers.
Hmm, IE is not supported, you ask? Since Microsoft stopped support for IE, no more development for IE in future, and we will expect very less number of users use IE.
The specs of Fetch API is described here, https://fetch.spec.whatwg.org/
Check it out if you want to learn details about Fetch. In short, fetch()
is being used in following form:
fetch(ENDPOINT, OPTIONS).then( response => {
// do something with response
}).catch(error => {
// do something with error
});
ENDPOINT is the API target endpoint that you want to make actual requests to.
OPTIONS is the Request object.
Since fetch()
returns a Promise, so you can handle it in chain with then()
and catch()
as usual.
The data return from Fetch API is a Response object.
Aright, let’s try some examples to work with Fetch API.
Query random-user API:
fetch('https://randomuser.me/api/').then(response => {
if(response.ok) return response.json();
}).then(data => {
console.log('Data', data);
}).catch(err => {
console.log(err);
});
To get actual data, we have to resolve and call response.json()
in order to get actual content returned by the API endpoint.
If there is any error, you can easily handle it through Promise.catch()
.
By default, fetch()
assumes that you use GET method. In case, you want to use other HTTP methods like POST, PUT, DELETE, PATCH… add method
to the request options.
fetch(ENDPOINT, { method: 'POST' })
You can put any custom header value by adding into the headers
property of request options.
fetch(ENDPOINT, {
headers: {
"Content-Type": "application/json",
}
)
To post data, you will need to include post data into body
property of request options.
So, to request JSON data:
fetch(ENDPOINT, {
method: 'POST',
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({ name: "Pete Houston" })
})
To request form data:
fetch(ENDPOINT, {
method: 'POST',
headers: {
"Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
},
body: "name=Pete%20Houston"
})
To do this, use the credentials
property.
credentials: "include"
In order for older browsers to use fetch()
, there is a polyfill made by Github, https://github.com/github/fetch
Fetch API is fairly simple to learn and implement into any web app. Since most of modern browsers support it, why not make use of it to cut down the cost of unnecessary cost of third-party libraries! It is a good thing for the web.
Transport Layer Security is on the short list for “most important security protocol on the Internet.” It is designed to enable client-server applications like web browsers and servers to securely communicate over the Internet, protecting against eavesdropping, tampering, and message forgery. Each party can know that the other is who they claim to be.
TLS is the technological descendant of Secure Sockets Layer and is often referred to casually as SSL. The earlier SSL versions were developed by Netscape Communications. In the late 1990s, after AOL bought Netscape, the Internet Engineering Task Force (IETF) took over the protocol. Version 1.0 of TLS had only small differences compared with SSL 3.0. For purposes here, I’ll use the name TLS, except where making historical references to old versions. The current version of TLS is 1.3, defined in RFC 8446.
We all know TLS from the lock icon in web browsers, showing that the site is secure, but the world of TLS is much bigger than that. It has three major functions:
The better known and more complicated part of TLS encryption is the asymmetric part, usually using public key infrastructure (PKI). The encryption in the actual data communications is symmetric, using keys that were generated, exchanged, and agreed upon by the parties using the asymmetric handshaking part of TLS.
Symmetric encryption is designed for speed and security. Examples of symmetric algorithms are Twofish and the now-dominant Advanced Encryption Standard (AES). Asymmetric encryption establishes a secure connection between two parties that don’t necessarily trust each other.
Digital certificates with public keys, identities, and signatures are used by the parties in a TLS communication to identify each other and generate keys. Usually, but optionally, the certificates are issued by a trusted third party, called a certificate authority (CA). The parties can use public key encryption algorithms and communicate with the CA to “prove” (given some assumptions) that the party that issued the certificate is in fact who they claim to be. This is how the browser knows, for example, that the website www.hpe.com is actually Hewlett Packard Enterprise.
The MAC is conceptually similar to a cryptographic hash in that it allows a recipient to use it to prove that the message content has not been modified. However, it has different forms of attack in mind. TLS is a TCP-based protocol, but there is a User Datagram Protocol version called Datagram Transport Layer Security. The application using DTLS has to deal with packet loss and reordering with encrypted data, but it avoids problems that can occur, for example, in virtual private networks, when TCP is encapsulated in a TCP tunnel.
The negotiation between a client and server when establishing a TLS connection is called the handshake, described broadly below. The full version, in grinding detail, is found in the specification.
All TLS handshakes authenticate the server to the client. They can, but don’t have to, authenticate the client to the server. The basic handshake, the type used when you connect to a TLS website such as a bank, does not authenticate a client. (It’s worth noting that the handshake changed quite a bit in TLS 1.3, the current, but still emerging, new version.)
In the basic handshake, the client begins with a ClientHello message to the server. This message specifies the highest TLS version it can support and suggested protocols, like cipher suites, it wishes to use. It also specifies a key agreement algorithm and a key share for the algorithm. This is enough for the server to finish the handshake and reply with encrypted packets, initially sending the algorithms it has chosen, a digital certificate containing keys, and a digital signature. (The TLS 1.2 handshake had an extra set of round trips between the client and server, and so TLS 1.3 is potentially much faster to connect.)
At the end of the process, the client has the information with which it can authenticate the server using the digital signatures returned in the handshake. It does so by checking the certificate with the issuing certificate authority.
Netscape created SSL in order to permit encrypted communications between the browser and server. At that time, people were just beginning to do serious things with the web, such as sending credit card numbers, which meant some attempt at security was necessary. And so SSL and then TLS became the standard method of providing and indicating security in web browsers. This is certainly the most common application of it, but there are many others.
Many of the important Internet protocols that began as clear-text (unencrypted) protocols, just as HTTP began, have been augmented with TLS capabilities:
These days, many applications use a web browser as the interface and so get TLS for free as part of HTTPS.
There are many implementations of SSL. Use them. There is a rule in programming about encryption: It’s very hard to do it right. Now and then people attempt to roll their own and they usually get into trouble.
As with all software, it’s important with TLS to pay attention to vulnerability disclosures and updates, and to apply the updates quickly. There is a general appreciation of the importance of this practice for operating systems and some major applications, so updates to Windows Secure Channel, Apple Secure Transport and Mozilla NSS are likely to be updated quickly. This is not necessarily so for less prominent and in-house applications built with OpenSSL or some other library. These applications may need to be reissued or updated by the authors.
Each major version of TLS, at least since 1.1, has included important security improvements. Over time, old versions have been declared “prohibited.” In March 2011, the IETF published RFC 6176, requiring that clients and servers “never negotiate the use of Secure Sockets Layer (SSL) version 2.0.” In June 2015, RFC 7568 required that “SSLv3 not be used.”
In October of 2018, Apple, Google, Microsoft, and Mozilla all declared that they would deprecate TLS 1.0 and 1.1 in their products in or around March 2020. Every significant and currently supported TLS implementation supports version 1.2. In some old versions of Windows, TLS 1.2 is not enabled by default, but these versions will have reached their expiration dates by the time TLS 1.0 and 1.1 are put out to pasture.
Version 1.0 was not significantly different from SSL 3.0, but it was different enough that it was not interoperable with the old version. Because of market realities at the time of release, it contains a mechanism through which the TLS 1.0 server could revert to SSL 3.0. In effect, this was a vulnerability making all SSL 3.0 problems also problems in TLS 1.0.
The vulnerability addressed in TLS 1.1, released in April 2006 as RFC 4346, was cipher block chaining attacks. This is a class of attack with which an attacker can use protocol weaknesses in version 1.0 to encrypt and decrypt data without the key, where certain ciphers are used.
TLS 1.2 was published in August 2008 as RFC 5246, removing support for old and weak cryptography functions and strengthening many security features. Examples include:
The changes in TLS 1.2 underscore how TLS is a complex collection of cryptographic functions and rules for how they are to be used. As with all security, these individual functions are improved over time, if only by using larger values to increase the cost of brute force attacks.
The authors of TLS 1.3, released as RFC 8446 in August 2018, took a more comprehensive look at the TLS design and changed some of the protocol to improve performance of the algorithms and the organization and logic of the security features. In the section above on the TLS handshake, I described the 1.3 version of it. The 1.2 version is much more complicated and longer.
So 1.3 is much better, but it is new and different. As a result, implementation has taken a while. As of late 2018, only a few implementations have been released. Some of these, when released, exposed incompatibilities with significant products in the wild, generally causing the TLS authors to not make 1.3 the default version. Important vendors like Apple and Microsoft have not yet released TLS 1.3 implementations.
In terms of security, TLS 1.3 removes more old and weak algorithms, even whole classes of algorithms. It mandates support for perfect forward secrecy—which protects past session data from compromise in the event of a future key compromise—adds a session hash, and adds new, stronger algorithms for MAC, digital signatures, and key exchange.
I’ve written before about how experts are concerned about the possibility that asymmetric encryption algorithms, such as those used in TLS, will become easily crackable in an era of quantum computers. Even though this prospect is many years away, there are experts at the National Institute of Standards and Technology working on new algorithms that will survive attacks by quantum cracking.
TLS gets this level of attention because it and the PKI on which it relies are, if this can be said of any algorithm, critical infrastructure. Without TLS, our financial data, our medical data, military communications, and everything else that is important and sensitive would be exposed to the world. Just about everyone, whether they know it or not, needs TLS to work.