Skip to content

Males-For-Females-llc/ominous-sniffle

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GitHub Codespaces ♥️ React

Welcome to your shiny new Codespace running React! We've got everything fired up and running for you to explore React.

You've got a blank canvas to work on from a git perspective as well. There's a single initial commit with the what you're seeing right now - where you go from here is up to you!

Everything you do here is contained within this one codespace. There is no repository on GitHub yet. If and when you’re ready you can click "Publish Branch" and we’ll create your repository and push up your project. If you were just exploring then and have no further need for this code then you can simply delete your codespace and it's gone forever.

This project was bootstrapped for you with Create React App.

Available Scripts

In the project directory, you can run:

npm start

We've already run this for you in the Codespaces: server terminal window below. If you need to stop the server for any reason you can just run npm start again to bring it back online.

Runs the app in the development mode.
Open http://localhost:3000 in the built-in Simple Browser (Cmd/Ctrl + Shift + P > Simple Browser: Show) to view your running application.

The page will reload automatically when you make changes.
You may also see any lint errors in the console.

npm test

Launches the test runner in the interactive watch mode.
See the section about running tests for more information.

npm run build

Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

See the section about deployment for more information.

npm run eject

Note: this is a one-way operation. Once you eject, you can't go back!

If you aren't satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.

Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you're on your own.

You don't have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn't feel obligated to use this feature. However we understand that this tool wouldn't be useful if you couldn't customize it when you are ready for it.

Learn More

You can learn more in the Create React App documentation.

To learn React, check out the React documentation.

Code Splitting

This section has moved here: https://facebook.github.io/create-react-app/docs/code-splitting

Analyzing the Bundle Size

This section has moved here: https://facebook.github.io/create-react-app/docs/analyzing-the-bundle-size

Making a Progressive Web App

This section has moved here: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app

Advanced Configuration

This section has moved here: https://facebook.github.io/create-react-app/docs/advanced-configuration

Deployment

This section has moved here: https://facebook.github.io/create-react-app/docs/deployment

npm run build fails to minify

This section has moved here: https://facebook.github.io/create-react-app/docs/troubleshooting#npm-run-build-fails-to-minify

Welcome to your organization's demo respository

This code repository (or "repo") is designed to demonstrate the best GitHub has to offer with the least amount of noise.

The repo includes an index.html file (so it can render a web page), two GitHub Actions workflows, and a CSS stylesheet dependency.

This workflow uses actions that are not certified by GitHub.

They are provided by a third-party and are governed by

separate terms of service, privacy policy, and support

documentation.

This workflow lets you generate SLSA provenance file for your project.

The generation satisfies level 3 for the provenance requirements - see https://slsa.dev/spec/v0.1/requirements

The project is an initiative of the OpenSSF (openssf.org) and is developed at

The provenance file can be verified using https://github.com/slsa-framework/slsa-verifier.

For more information about SLSA and how it improves the supply-chain, visit slsa.dev.

name: SLSA generic generator on: workflow_dispatch: release: types: [created]

jobs: build: runs-on: ubuntu-latest outputs: digests: ${{ steps.hash.outputs.digests }}

steps:
  - uses: actions/checkout@v3

  # ========================================================
  #
  # Step 1: Build your artifacts.
  #
  # ========================================================
  - name: Build artifacts
    run: |
        # These are some amazing artifacts.
        echo "artifact1" > artifact1
        echo "artifact2" > artifact2

  # ========================================================
  #
  # Step 2: Add a step to generate the provenance subjects
  #         as shown below. Update the sha256 sum arguments
  #         to include all binaries that you generate
  #         provenance for.
  #
  # ========================================================
  - name: Generate subject for provenance
    id: hash
    run: |
      set -euo pipefail

      # List the artifacts the provenance will refer to.
      files=$(ls artifact*)
      # Generate the subjects (base64 encoded).
      echo "hashes=$(sha256sum $files | base64 -w0)" >> "${GITHUB_OUTPUT}"

provenance: needs: [build] permissions: actions: read # To read the workflow path. id-token: write # To sign the provenance. contents: write # To add assets to a release. uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected] with: base64-subjects: "${{ needs.build.outputs.digests }}" upload-assets: true # Optional: Upload to a new release

polkadot{.js} extension

A very simple scaffolding browser extension that injects a @polkadot/api Signer into a page, along with any associated accounts, allowing for use by any dapp. This is an extensible POC implementation of a Polkadot/Substrate browser signer.

As it stands, it does one thing: it only manages accounts and allows the signing of transactions with those accounts. It does not inject providers for use by dapps at this early point, nor does it perform wallet functions where it constructs and submits txs to the network.

Installation

interface screenshots

Documentation and examples

Find out more about how to use the extension as a Dapp developper, cookbook, as well as answers to most frequent questions in the Polkadot-js extension documentation

Development version

Steps to build the extension and view your changes in a browser:

  1. Build via yarn build
  2. Install the extension
  • Chrome:
    • go to chrome://extensions/
    • ensure you have the Development flag set
    • "Load unpacked" and point to packages/extension/build
    • if developing, after making changes - refresh the extension
  • Firefox:
    • go to about:debugging#addons
    • check "Enable add-on debugging"
    • click on "Load Temporary Add-on" and point to packages/extension/build/manifest.json
    • if developing, after making changes - reload the extension
  1. When visiting https://polkadot.js.org/apps/ it will inject the extension

Once added, you can create an account (via a generated seed) or import via an existing seed. The apps UI, when loaded, will show these accounts as (extension)

Development

The repo is split into a number of packages -

  • extension - All the injection and background processing logic (the main entry)
  • extension-ui - The UI components for the extension, to build up the popup
  • extension-dapp - A convenience wrapper to work with the injected objects, simplifying data extraction for any dapp that wishes to integrate the extension (or any extension that supports the interface)
  • extension-inject - A convenience wrapper that allows extension developers to inject their extension for use by any dapp

Dapp developers

The actual in-depth technical breakdown is given in the next section for any dapp developer wishing to work with the raw objects injected into the window. However, convenience wrappers are provided that allows for any dapp to use this extension (or any other extension that conforms to the interface) without having to manage any additional info.

The documentation for Dapp development is available in the polkadot-js doc.

This approach is used to support multiple external signers in for instance apps. You can read more about the convenience wrapper @polkadot/extension-dapp along with usage samples.

API interface

The extension injection interfaces are generic, i.e. it is designed to allow any extension developer to easily inject extensions (that conforms to a specific interface) and at the same time, it allows for any dapp developer to easily enable the interfaces from multiple extensions at the same time. It is not an all-or-nothing approach, but rather it is an ecosystem where the user can choose which extensions fit their style best.

From a dapp developer perspective, the only work needed is to include the @polkadot/extension-dapp package and call the appropriate enabling function to retrieve all the extensions and their associated interfaces.

From an extension developer perspective, the only work required is to enable the extension via the razor-thin @polkadot/extension-inject wrapper. Any dapp using the above interfaces will have access to the extension via this interface.

When there is more than one extension, each will populate an entry via the injection interface and each will be made available to the dapp. The Injected interface, as returned via enable, contains the following information for any compliant extension -

interface Injected {
  // the interface for Accounts, as detailed below
  readonly accounts: Accounts;
  // the standard Signer interface for the API, as detailed below
  readonly signer: Signer;
  // not injected as of yet, subscribable provider for polkadot-js API injection,
  // this can be passed to the API itself upon construction in the dapp
  // readonly provider?: Provider
}

interface Account = {
  // ss-58 encoded address
  readonly address: string;
  // the genesisHash for this account (empty if applicable to all)
  readonly genesisHash?: string;
  // (optional) name for display
  readonly name?: string;
};

// exposes accounts
interface Accounts {
  // retrieves the list of accounts for right now
  get: () => Promise;
  // (optional) subscribe to all accounts, updating as they change
  subscribe?: (cb: (accounts: Account[]) => any) => () => void
}

// a signer that communicates with the extension via sendMessage
interface Signer extends SignerInterface {
  // no specific signer extensions, exposes the `sign` interface for use by
  // the polkadot-js API, confirming the Signer interface for this API
}

Injection information

The information contained in this section may change and evolve. It is therefore recommended that all access is done via the @polkadot/extension-dapp (for dapps) and extension-inject (for extensions) packages, which removes the need to work with the lower-level targets.

The extension injects injectedWeb3 into the global window object, exposing the following: (This is meant to be generic across extensions, allowing any dapp to utilize multiple signers, and pull accounts from multiples, as they are available.)

window.injectedWeb3 = {
  // this is the name for this extension, there could be multiples injected,
  // each with their own keys, here `polkadot-js` is for this extension
  'polkadot-js': {
    // semver for the package
    version: '0.1.0',

    // this is called to enable the injection, and returns an injected
    // object containing the accounts, signer and provider interfaces
    // (or it will reject if not authorized)
    enable (originName: string): Promise
  }
}

Mnemonics, Passwords, and Imports/Exports

Using the mnemonic and password from the extension

When you create a keypair via the extension, it supplies a 12-word mnemonic seed and asks you to create a password. This password only encrypts the private key on disk so that the password is required to spend funds in polkadot-js/apps or to import the account from backup. The password does not protect the mnemonic phrase. That is, if an attacker were to acquire the mnemonic phrase, they would be able to use it to spend funds without the password.

Importing mnemonics from other key generation utilities

Some key-generation tools, e.g. Subkey, support hard and soft key derivation as well as passwords that encrypt the mnemonic phrase such that the mnemonic phrase itself is insufficient to spend funds.

The extension supports these advanced features. When you import an account from a seed, you can add these derivation paths or password to the end of the mnemonic in the following format:

//////

That is, hard-derivation paths are prefixed with //, soft paths with /, and the password with ///.

The extension will still ask you to enter a password for this account. As before, this password only encrypts the private key on disk. It is not required to be the same password as the one that encrypts the mnemonic phrase.

Accounts can also be derived from existing accounts – Derive New Account option in account's dropdown menu should be selected. After providing the password of the parent account, along with name and password of the derived account, enter derivation path in the following format:

///

The path will be added to the mnemonic phrase of the parent account.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published