Tiny utility to hash the timestamp
Generate hashes from javascript objects in node and the browser.
JWA implementation (supports all JWS algorithms)
An incremental implementation of MurmurHash3
A MurmurHash2 implementation
Implementation of JSON Web Signatures
Hashing made simple. Get the hash of a buffer/string/stream/file.
abstract base class for hash-streams
Generates a hash for an installed npm package, useful for salting caches
Stable JS value hash.
Capture and retrieve the last time a function was run
Lightning fast normal and incremental md5 for javascript
create hashes for browserify
oidc-token-hash validates (and generates) ID Token `_hash` claims such as `at_hash` or `c_hash`
Stable JS value hash.
A collection of utilities for better-auth
Hash utility functions for Ethereum.
An mutable object-based log format designed for chaining & objectMode streams.
RFC9562 UUIDs
Pure Javascript implementation of the BLAKE2b and BLAKE2s hash functions
A pure JS implementation SHA256.
Lightning fast hash functions for browsers and Node.js using hand-tuned WebAssembly binaries (MD4, MD5, SHA-1, SHA-2, SHA-3, Keccak, BLAKE2, BLAKE3, PBKDF2, Argon2, bcrypt, scrypt, Adler-32, CRC32, CRC32C, RIPEMD-160, HMAC, xxHash, SM3, Whirlpool)
The keccak256 hash function for ethers.
A tiny (952b), correct, general-purpose, and configurable "exports" and "imports" resolver without file-system reliance
A lightweight audit trail library for tracking changes to hashes and objects with actor, action, diff, and timestamp support.
This gem is a logstash plugin required to be installed on top of the Logstash core pipeline using $LS_HOME/bin/plugin install gemname. This gem is not a stand-alone program
Keyless Signatures are a combination of hash function based server-side signatures and hash-linking based digital timestamping delivered using a distributed and hierarchical infrastructure. This extension provides high-level API to access the KSI.
Minimal, simple, DRY DSL for searching Elasticsearch. Takes one shallow hash argument and translates it to an elaborate one passed on to elasticsearch-api. The price: narrower options. The gain: succinctness. For example, a root <tt>:range</tt> is always a boolean filter and always includes the edges: tractor = Client.new opts = { range: { timestamp: ['now-5m', 'now'] } } tractor.search(opts) # => sends the following to Ealsticsearch: { "query": { "bool": { "filter": [ { "range": { "timestamp": { "gte":"now-5m", "lte":"now" } } } ], "must": [], } } }
Temporally Ordered IDs. Generate universally unique identifiers (UUID) that sort lexically in time order. Torid exists to solve the problem of generating UUIDs that when ordered lexically, they are also ordered temporally. I needed a way to generate ids for events that are entering a system with the following criteria: 1. Fast ID generation 2. No central coordinating server/system 3. No local storage 4. Library code, that is multiple apps on the same machine can use the same code and they will not generate duplicate ids 5. Eventually stored in a UUID field in a database. So 128bit ids are totally fine. The IDs that Torid generates are 128bit IDs made up of 2, 64bit parts. * 64bit microsecond level UNIX timestamp * 64bit hash of the system hostname, process id and a random value.
= DESCRIPTION: Provides a Chef handler which can report run status, including any changes that were made, to a rabbit server. In the case of failed runs a backtrace will be included in the details reported. Based on the Graylog Gelf handler by Jon Wood (<jon@blankpad.net>) https://github.com/jellybob/chef-gelf = REQUIREMENTS: * A Rabbit server running somewhere. = USAGE: This example makes of the chef_handler cookbook, place some thing like this in cookbooks/chef_handler/recipes/rabbit.rb and add it to your run list. include_recipe "chef_handler::default" gem_package "chef-rabbit" do action :nothing end.run_action(:install) # Make sure the newly installed Gem is loaded. Gem.clear_paths require 'chef/rabbit' chef_handler "Chef::RABBIT::Handler" do source "chef/rabbit" arguments({ :connection => { :host => "your_rabbit_server", :user => "rabbit_user", :pass => "rabbit_pass", :vhost => "/stuff" } :queue => { :name => "some_queue", :params => { :durable => true, ... } }, :exchange => { :name => "some_exchange", :params => { :durable => true, ... } }, :timestamp_tag => "@timestamp" }) supports :exception => true, :report => true end.run_action(:enable) Arguments take the form of an options hash, with the following options: * :connection - http://rubybunny.info/articles/connecting.html * :queue - rabbit queue info to use. name is set to "chef-client" + durable = true by default * :exchange - rabbit exchange to use .default_exchange + durable = true by default * :timestamp_tag - tag for timestamp "timestamp" by default * :blacklist ({}) - A hash of cookbooks, resources and actions to ignore in the change list. = BLACKLISTING: Some resources report themselves as having updated on every run even if nothing changed, or are just things you don't care about. To reduce the amount of noise in your logs these can be ignored by providing a blacklist. In this example we don't want to be told about the GELF handler being activated: chef_handler "Chef::RABBIT::Handler" do source "chef/rabbit" arguments({ :blacklist => { "chef_handler" => { "chef_handler" => [ "nothing", "enable" ] } } }) supports :exception => true, :report => true end.run_action(:enable) = LICENSE and AUTHOR: Copyright 2014 by MTN Satellite Communications Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
# Quick Start The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS). Let’s assume that the access token provided by your account manager is “TOKEN”. Here’s how to get the list of ids of all your invoices from the first week of August with a shell script: ```bash query="end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00" curl -i "https://api-eu.getaround.com/owner/v1/invoices?${query}" \ -H "Authorization: Bearer TOKEN" \ -H "Accept:application/json" \ -H "Content-Type:application/json" ``` And here’s how to get the invoice with the id 12345: ```bash curl -i "https://api-eu.getaround.com/owner/v1/invoices/12345" \ -H "Authorization: Bearer TOKEN" \ -H "Accept: application/json" \ -H "Content-Type: application/json"" ``` See the [endpoints section](#tag/Invoices) of this guide for details about the response format. Dates in request params should follow the ISO 8601 standard. # Authentication All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager. Unauthenticated requests will return a 401 status. # Pagination The page number and the number of items per page can be set with the “page” and “per_page” params. For example, this request will return the second page of invoices, and 50 invoices per page: `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` Both of these params are optional. The default page size is 30 items. The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page. Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel="next" ``` # Throttling policy and Date range limitation We have throttling policy that prevents you to perform more than 100 requests per min from the same IP. Also, there is a limitation on the size of the range of dates given in params in some requests. All requests that need start_date and end_date, do not accept a range bigger than 30 days. # Webhooks Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations. ### Setup To set up an endpoint, you need to define a route on your server for receiving events, and then <a href="mailto:owner-api@getaround.com">ask Getaround</a> to add this URL to your account. To acknowledge receipt of a event, your endpoint must: - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate. ### Testing Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below: <form action="/docs/api/owner/fire_ping_webhook" method="post"><input type="submit" value="Send Ping Event"></form> You should receive the following JSON payload: ```json { "data": { "ping": "pong" }, "type": "ping", "occurred_at": "2019-04-18T08:30:05Z" } ``` ### Retries Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned. ### Verifying Signatures Getaround will also provide you with a secret token, which is used to create a hash signature with each payload. This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this: ```ruby require 'sinatra' require 'json' post '/payload' do push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end ``` The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this: ```ruby post '/payload' do request.body.rewind payload_body = request.body.read verify_signature(payload_body) push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end def verify_signature(payload_body) signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body) return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ``` Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however: No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body. Using a plain `==` operator is not advised. A method like secure_compare performs a "constant time" string comparison, which renders it safe from certain timing attacks against regular equality operators. ### Best Practices - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering.