Caryln Canary

1550283374

Nuxtjs router go, routing _slug

i'm a novice in nuxtjs. I have a following structure:

pages/
--| items/
-----| /info
---------| _slug.vue

I have a route 'website/items/info/39dj83'.

Where '39dj83' is a dynamic variable, that i got from API.

How can i redirect user to that route?

I'm trying something like this:

this.$router.push({name : 'items-info-slug', ???});

How can i send a slug '39dj83'??

Is my structure corrent?

Also how can i get this slug '39dj83' in my slug.vue component?

#nuxt-js

What is GEEK

Buddha Community

Elthel Mario

1550455909

this.$router.push({name : 'items-info-slug',params: { slug: '39dj83' }});

Docs

In your _slug.vue you can access it via params. E.g.

fetch({params}) {
  console.log(params.slug)
}

Docs

Fannie  Zemlak

Fannie Zemlak

1599854400

What's new in the go 1.15

Go announced Go 1.15 version on 11 Aug 2020. Highlighted updates and features include Substantial improvements to the Go linker, Improved allocation for small objects at high core counts, X.509 CommonName deprecation, GOPROXY supports skipping proxies that return errors, New embedded tzdata package, Several Core Library improvements and more.

As Go promise for maintaining backward compatibility. After upgrading to the latest Go 1.15 version, almost all existing Golang applications or programs continue to compile and run as older Golang version.

#go #golang #go 1.15 #go features #go improvement #go package #go new features

What is Router Protocol (ROUTE) | What is Router Protocol token | What is ROUTE token

Router Protocol is a crosschain-liquidity aggregator platform that was built to seamlessly provide bridging infrastructure between current and emerging Layer 1 and Layer 2 blockchain solutions. The goal is to enable users to swap their assets from different networks seamlessly in a near-instant and low-cost manner

On cross-chain liquidity: Introducing the Router Protocol

Image for post

As a multi blockchain future becomes a reality, there is a critical need for infrastructure that can port liquidity across chains for the ecosystem to develop.

Ethereum has been great — It is the first Turing-complete, trustless ‘world computer’ of its kind. And we are just tapping into the full potential of Ethereum, which should be unleashed with Eth 2.0 and its transition to POS over the coming months and years.

However the fact remains that, scalability efforts are still in their early days, as most platforms continue with the scalability trilemma — the trade off between decentralization, scalability and security. Layer 2 solutions include Bitcoin’s Lightning network, as well as multiple solutions for Ethereum such as Plasma. Layer 1 solutions include Sharding, as well as consensus protocol changes that inevitably involve various sliding-scale trade offs across the axes of the scalability trilemma. While Eth 2.0 promises tps (transactions per second) figures of over 100000 at some point in the future, there are significant technical hurdles to be overcome before the sharding in ETH 2.0 can get there. In the meanwhile, most major blockchain solutions offer tps figures far less than that seen on Visa, Mastercard or PayPal, which are atleast 1500 tps, even from a conservative standpoint.

Image for post

Therefore we have multiple efforts addressed towards scalability — In addition to Eth 2.0 there are consensus protocol approaches such as Dfinity, Tezos, Polka and Cosmos as well as Layer 2 solutions such as Matic, Omisego, xDAI etc. There is no one conclusive winner yet, and it might be that the future of blockchains will be multi-chain for quite a while, with a fragmented market with liquidity and developer community dispersed across these.

In this scenario, what will be needed is the infra that will seamlessly port liquidity between these isolated liquidity pools, almost like highways connecting far flung cities. The development of railways starting in the early 1800s helped develop the US economy and laid foundations for it to become the super power of the 20th century; This also led to the development of various cities across the United States. Similarly, cross-chain bridging infrastructure will help promote liquidity migration and developer efforts towards various emerging chains and solutions, and eventually lead to a thriving, bustling blockchain ecosystem.

Router is a cross chain liquidity infrastructure primitive that aims to seamlessly provide bridging infra between various current and emerging layer-1 and layer-2 blockchain solutions, such as Matic and Ethereum.

Progressively, Router plans to build out bridging infra between multiple other chains in its roadmap. Stay tuned as we roll out the product and expand on our roadmap over the coming few weeks.

Router Protocol is set on building a cross-chain future

Image for post

The decentralized ecosystem consists of over 6,000 cryptocurrencies that currently operate in closed-off, isolated infrastructures, unable to access neither the liquidity nor the functionality offered by each other. Protocols and communities across the entire industry are continually battling each other to claim their spot in the emerging Web 3.0 paradigm. And while the rise of Web 3.0 is inevitable, it’s still too early to tell what the ecosystem will look like — will it evolve into a monopoly, with the entire space dominated by a single blockchain platform, or will it turn into an oligopoly, where a handful of protocols control the market?

What is clear, however, is the need for bridging these fragmented networks. With these 6,000 different cryptocurrencies on the market encapsulating over $752 billion in value, there has never been a more pressing need for porting liquidity across them. As more institutional investors join the crypto space, the need for better efficiency and flexibility increases almost exponentially.

The crypto industry was built on a fundamental premise; the fragmentation and limitations endemic to traditional finance needed to be replaced with a better, more robust system built with user needs front and center. The world of traditional finance, while dealing with a wide variety of asset classes, is a deeply flawed one — the limitations it essentially put upon itself do more to facilitate rent-seeking behavior than actually benefiting its users. Unfortunately, several of these legacy encumbrances have been grandfathered into our new world of blockchains.

When the need to transfer assets from one blockchain system to another occurs, users are kept in the dark on exactly what goes on under the hood, and are forced to pay high fees to facilitate technically simple transfers. For example, when writing this post — the cost of transferring value on Ethereum is almost at all-time high of $10+ and if you want to use a service like Uniswap to swap tokens — the fees is north of $50.

Router Protocol wants to resolve this issue, which is becoming increasingly important as the world gets more globally connected. We at Router believe that the future lies in cross-chain interoperability. The crypto industry doesn’t have to suffer from the fragmentation seen in traditional finance.

One of the most integral parts of the emerging Web 3.0 paradigm is liquidity farming. While opinions are divided on the topic, liquidity farming is here to stay and should be seen as a largely positive development in the crypto industry. Unlike the data farming that shaped the Web 2.0 era, yield farming in the Web 3.0 ecosystem will provide users with real, tangible benefits — a steady trickle of yield.

With Web 3.0 being all about startups building products around various facets of capital flows, the rise of financial primitives such as loans seems inevitable.

But, the trustless, open-source nature of the emerging Web 3.0 ecosystem is set to result in a large number of closed-off projects, each competing for a tiny part of the market. Such a fragmented market is set to produce multiple Layer 1 and Layer 2 solutions working to make their systems more efficient.

As a cross-chain liquidity infrastructure primitive, Router Protocol aims to provide a seamless bridge between those Layer 1 and Layer 2 blockchain platforms. Aside from connecting blockchains and enabling a free flow of information, Router will also make smart order-routing possible, enabling users to swap their assets from different networks seamlessly. Utilizing Router will be completely transparent and users will be able to see what goes on “under the hood” every time they interact with the protocol.

Liquidity Landscape after Router Protocol

Being transparent, however, doesn’t have to mean being complicated. Those interacting with Router Protocol will be able to enjoy a rather hands-off user experience — when swapping assets, the system will automatically find the best market price and execute the swap.

The first major product coming from Router Protocol will be a bridge between the Matic Network and Ethereum. A bridge between Matic and Ethereum will provide a scaling solution to Ethereum that is near-instant, low-cost, and incredibly flexible. It will enable users to get the best of both worlds — Matic users will reap the benefits of Ethereum’s unprecedented liquidity, while Ethereum users will be able to utilize Matic’s scalability and high throughput.

In the future, Router plans on building bridging infrastructure between multiple other blockchains and blockchain solutions. Stay tuned as we roll out new products and expand our roadmap in the coming weeks. Router protocol will extend interoperability to many different layers. We are currently considering Avalanche, Binance Smart Chain, Cardano, Algorand, Solana, Stellar, Polkadot, and Litecoin.

Total Supply: 20,000,000 ROUTE
Initial Circulating Supply: 1,022,865 ROUTE

Token Distribution

Seed Round: 600,000 ROUTE, 3.00% of Total Supply
Private Round: 1,521,818 ROUTE, 7.61% of Total Supply
Reward Pool: 3,444,000 ROUTE, 17.22% of Total Supply
Ecosystem Fund: 5,084,000 ROUTE, 25.42% of Total Supply
Team: 3,000,000 ROUTE, 15.00% of Total Supply
Liquidity Provision Fund: 350,000 ROUTE, 1.75% of Total Supply
Foundation: 4,000,000 ROUTE, 20.00% of Total Supply
Strategic Partners: 2,000,000 ROUTE, 10.00% of Total Supply

Token Vesting Schedule

Seed Round: Vesting over 15 months with 6 month cliff
Private Round: Vesting over 9 months
Reward Pool: Locked in Smart Contract for daily distribution over 12 months per reward programs
Ecosystem Fund: 8% unlock at day 0, 7% unlock at month 3, remaining distributed monthly 17 months
Team: 10% unlock at month 9, remaining distributed monthly for 12 months
Liquidity Provision Fund: 80,000 unlock at day 0, 30,000 at day 30, remaining distributed quarterly for 12 months
Foundation: 10% unlock at month 9, remaining distributed monthly for 12 months
Strategic Partners: Vesting over 12 months
Initial Circulating Supply at listing:1,022,865 ROUTE(5.11% of Total Supply), including:
-304,364 ROUTE from private investors unlock
-80,000 ROUTE from liquidity provision fund
-406,720 ROUTE from ecosystem fund
-31,371 ROUTE from reward pool
-200,000 ROUTE from strategic partners

Looking for more information…

WebsiteExplorerSource CodeSocial ChannelMessage BoardMessage Board 2Coinmarketcap

Would you like to earn ROUTE right now! ☞ CLICK HERE

Top exchanges for token-coin trading. Follow instructions and make unlimited money

BinanceBittrexPoloniexBitfinexHuobi

Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #bitcoin #crypto #router protocol #route

React.Js Router v5 in Examples.

All you need to know about using React.js _react-router-dom_ package and how to use it (with code and result GIF examples).

I will be using a starter Typescript React.js project that was created using most popular create-react-app script. No additional packages (only _eslint_ and _prettier_, but that is for code formatting 😉)

npx create-react-app my-app --template typescript
# or
yarn create react-app my-app --template typescript

… and I removed all styles. They will only distract us from the main topic.

Image for post

Image for post


What will be covered in this article:

  • 1. Installing
  • 2. Creating your first Routes using Switch
  • 3. Nested Routing
  • 4. Prompt component
  • 5. NavLink component
  • 6. 404 page (page not found)
  • 7. Getting Route props (match, location, history)
  • 8. Route Parameters
  • 9. URLSearchParams
  • 10. Redirect component
  • 11. Secure your application

1. Installing

To start using **React Router** we need to add it to our dependencies :

yarn add react-router-dom

// Because we are using typescript project
// we need to istall @types/react-router-dom package too
yarn add @types/react-router-dom

And that’s it, we are totally ready!


2. Creating your first Routes using Switch

Before we will use the functionality of React Router we will need to create first component pages that we will use for showing changes when user clicks on a **Link**:

Image for post

Next, we need to add Navigation and Routes components. (Obviously, we could write all in one Component but in this case, it will be harder to read and understand what is happening)

Navigation component:

Routes component:

Image for post

And a final touch… We need to wrap our application with **BrowserRouter** component (as **Router**):

In Router version 3 instead of using **_BrowserRouter_** -> **_HashRouter_** was used. When Router version 4 was released **_HashRouter_** became deprecated.

Let’s test it out:

Image for post

Image for post


Image for post

Warning icon

!!!_ I want to notice one thing about **_Route_** — it is not comparing routes in strict mode like “some-string” === “some-other-string”. To solve this issue you need to pass **_exact={true}_** property, or to wrap you routes with Switch and__ place them in right order._

Let’s position our three routes in “wrong” order, like this:

… then your Routes will not change, even if path is changing:

Image for post

#reactjs #router-dom #route #react #router

Mikel  Okuneva

Mikel Okuneva

1597618800

Netgear Won't Patch 45 Router Models Vulnerable to Serious Flaw

Netgear will not patch 45 router models that are vulnerable to a high-severity remote code execution flaw, the router company revealed last week. However, the company says that routers that won’t receive updates are outdated or have reached EOL (End of Life).

The remote code execution vulnerability in question, which was disclosed June 15, allows network-adjacent attackers to bypass authentication on vulnerable Netgear routers – sans authentication. The high-severity flaw affects 79 Netgear Wi-Fi routers and home gateway models – but Netgear says that 45 of those router models are outside of its “security support period.”

“Netgear has provided firmware updates with fixes for all supported products previously disclosed by ZDI and Grimm,” Netgear said in a press statement. “The remaining products included in the published list are outside of our support window. In this specific instance, the parameters were based on the last sale date of the product into the channel, which was set at three years or longer.”

A full list of the router models that won’t be patched – as well as those that have fixes being rolled out – is available on Netgear’s website.

“When we look at support windows, some of our products last five or six years, while others last only a few years,” David Henry, senior vice president of Connected Home products at Netgear, told Threatpost. “When we launch a product, as it gets old it goes into End of Life (EOL) and we stop building it and wind down [sales into the channel].”

For instance, one such Modem Router that won’t receive an update, the AC1450 series, is as old as 2009. Other router models, while newer, have reached EOL: The R6200 and R6200v2 wireless routers reached EOL in 2013 and 2016, respectively; while the Nighthawk R7300DST wireless router reached EOL in the first half of 2017, said Henry.

Regardless, Henry stressed that customers using both newer and older router models stay updated on security updates, as well as adopting best security practices, including turning off features like remote access or changing admin passwords (which he said is enforced by Netgear).

“I think it is really important that customers are paying attention to the updates we send out quarterly on our products,” said Henry.

The Flaw

According to the Zero Day Initiative (ZDI), which first disclosed the issue, the flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length, stack-based buffer. An attacker can leverage this flaw to execute code in the context of root, according to ZDI.

“Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the service to trusted machines,” according to ZDI. “Only the clients and servers that have a legitimate procedural relationship with the service should be permitted to communicate with it. This could be accomplished in a number of ways, most notably with firewall rules/whitelisting.”

#vulnerabilities #web security #flaw #netgear #r6700 #r7800 #remote code execution #router #router flaw #router model #vulnerability

Zander  Herzog

Zander Herzog

1596793260

Secure HTTPS servers in Go

In this article, we are going to look at some of the basic APIs of the http package to create and initialize HTTPS servers in Go.

Image for post

(source: unsplash.com)

In the “Simple Hello World Server” lesson, we learned about net/http package, how to create routes and how [ServeMux](https://golang.org/pkg/net/http/#ServeMux) works. In the “Running multiple HTTP servers” lesson, we learned about [Server](https://golang.org/pkg/net/http/#Server) structure and how to run multiple HTTP servers concurrently.

In this lesson, we are going to create an HTTPS server using both Go’s standard server configuration and custom configuration (using [_Server_](https://golang.org/pkg/net/http/#Server) structure). But before this, we need to know what HTTPS really is?

HTTPS is a big topic of discussion in itself. Hence while writing this lesson, I published an article just on “How HTTPS works?”. I advise you to read this lesson first before continuing this article. In this article, I’ve also described the encryption paradigm and SSL certificates generation process.


If we recall the simplest HTTP server example from previous lessons, we only need http.``[ListenAndServe](https://golang.org/pkg/net/http/#ListenAndServe) function to start an HTTP server and http.``[HandleFunc](https://golang.org/pkg/net/http/#HandleFunc) to register a response handler for a particular endpoint.

Image for post

(https://play.golang.org/p/t3sOenOYAzS)

In the example above, when we run the command go run server.go , it will start an HTTP server on port 9000. By visiting http://localhost:9000 URL in a browser, you will be able to see a Hello World! message on the screen.

Image for post

(http://localhost:9000)

As we know, the nil argument to ListenAndServe() call invokes Go to use the [DefaultServeMux](https://golang.org/pkg/net/http/#DefaultServeMux) response multiplexer, which is the default instance of ServeMux structure provided globally by the Go. The HandleFunc() call adds a response handler for a specific route on the multiplexer instance.

The http.ListenAndServe() call uses the Go’s standard HTTP server configuration, however, in the previous lesson, how we can customize a server using [Server](https://golang.org/pkg/net/http/#Server) structure type.

To start an HTTPS server, all we need do is to call ServerAndListenTLS method with some configuration. Just like ServeAndListen method, this method is available on both the http package and the Server structure.

The http.``[ServeAndListenTLS](https://golang.org/pkg/net/http/#ListenAndServeTLS) method uses the Go’s standard server implementation, however, both [Server](https://golang.org/pkg/net/http/#Server) instance and Server.``[ServeAndListenTLS](https://golang.org/pkg/net/http/#Server.ListenAndServeTLS) method can be configured for our needs.

#go-programming-language #go #golang-tutorial #go-programming #golang