The base exception for JSON errors.
This exception is raised if the nesting of parsed data structures is too deep.
This exception is raised if the required unicode support is missing on the system. Usually this means that the iconv library is not installed.
OpenSSL::Digest allows you to compute message digests (sometimes interchangeably called “hashes”) of arbitrary data that are cryptographically secure, i.e. a Digest implements a secure one-way function.
One-way functions offer some useful properties. E.g. given two distinct inputs the probability that both yield the same output is highly unlikely. Combined with the fact that every message digest algorithm has a fixed-length output of just a few bytes, digests are often used to create unique identifiers for arbitrary data. A common example is the creation of a unique id for binary documents that are stored in a database.
Another useful characteristic of one-way functions (and thus the name) is that given a digest there is no indication about the original data that produced it, i.e. the only way to identify the original input is to “brute-force” through every possible combination of inputs.
These characteristics make one-way functions also ideal companions for public key signature algorithms: instead of signing an entire document, first a hash of the document is produced with a considerably faster message digest algorithm and only the few bytes of its output need to be signed using the slower public key algorithm. To validate the integrity of a signed document, it suffices to re-compute the hash and verify that it is equal to that in the signature.
You can get a list of all digest algorithms supported on your system by running this command in your terminal:
openssl list -digest-algorithms
Among the OpenSSL 1.1.1 supported message digest algorithms are:
SHA224, SHA256, SHA384, SHA512, SHA512-224 and SHA512-256
SHA3-224, SHA3-256, SHA3-384 and SHA3-512
BLAKE2s256 and BLAKE2b512
Each of these algorithms can be instantiated using the name:
digest = OpenSSL::Digest.new('SHA256')
“Breaking” a message digest algorithm means defying its one-way function characteristics, i.e. producing a collision or finding a way to get to the original data by means that are more efficient than brute-forcing etc. Most of the supported digest algorithms can be considered broken in this sense, even the very popular MD5 and SHA1 algorithms. Should security be your highest concern, then you should probably rely on SHA224, SHA256, SHA384 or SHA512.
data = File.binread('document') sha256 = OpenSSL::Digest.new('SHA256') digest = sha256.digest(data)
data1 = File.binread('file1') data2 = File.binread('file2') data3 = File.binread('file3') sha256 = OpenSSL::Digest.new('SHA256') sha256 << data1 sha256 << data2 sha256 << data3 digest = sha256.digest
Digest instance data1 = File.binread('file1') sha256 = OpenSSL::Digest.new('SHA256') digest1 = sha256.digest(data1) data2 = File.binread('file2') sha256.reset digest2 = sha256.digest(data2)
Generic error, common for all classes under OpenSSL module
If an object defines encode_with, then an instance of Psych::Coder will be passed to the method when the object is being serialized. The Coder automatically assumes a Psych::Nodes::Mapping is being emitted. Other objects like Sequence and Scalar may be emitted if seq= or scalar= are called, respectively.
Socket::Option represents a socket option used by BasicSocket#getsockopt and BasicSocket#setsockopt. A socket option contains the socket family, protocol level, option name optname and option value data.
Objects of class File::Stat encapsulate common status information for File objects. The information is recorded at the moment the File::Stat object is created; changes made to the file after that point will not be reflected. File::Stat objects are returned by IO#stat, File::stat, File#lstat, and File::lstat. Many of these methods return platform-specific values, and not all values are meaningful on all systems. See also Kernel#test.
Class representing an HTTP cookie.
In addition to its specific fields and methods, a Cookie instance is a delegator to the array of its values.
See RFC 2965.
cookie1 = CGI::Cookie.new("name", "value1", "value2", ...)
cookie1 = CGI::Cookie.new("name" => "name", "value" => "value")
cookie1 = CGI::Cookie.new('name' => 'name',
'value' => ['value1', 'value2', ...],
'path' => 'path', # optional
'domain' => 'domain', # optional
'expires' => Time.now, # optional
'secure' => true, # optional
'httponly' => true # optional
)
cgi.out("cookie" => [cookie1, cookie2]) { "string" }
name = cookie1.name
values = cookie1.value
path = cookie1.path
domain = cookie1.domain
expires = cookie1.expires
secure = cookie1.secure
httponly = cookie1.httponly
cookie1.name = 'name'
cookie1.value = ['value1', 'value2', ...]
cookie1.path = 'path'
cookie1.domain = 'domain'
cookie1.expires = Time.now + 30
cookie1.secure = true
cookie1.httponly = true
Exception raised when there is an invalid encoding detected
This file provides the CGI::Session class, which provides session support for CGI scripts. A session is a sequence of HTTP requests and responses linked together and associated with a single client. Information associated with the session is stored on the server between requests. A session id is passed between client and server with every request and response, transparently to the user. This adds state information to the otherwise stateless HTTP request/response protocol.
A CGI::Session instance is created from a CGI object. By default, this CGI::Session instance will start a new session if none currently exists, or continue the current session for this client if one does exist. The new_session option can be used to either always or never create a new session. See new() for more details.
delete() deletes a session from session storage. It does not however remove the session id from the client. If the client makes another request with the same id, the effect will be to start a new session with the old session’s id.
The Session class associates data with a session as key-value pairs. This data can be set and retrieved by indexing the Session instance using ‘[]’, much the same as hashes (although other hash methods are not supported).
When session processing has been completed for a request, the session should be closed using the close() method. This will store the session’s state to persistent storage. If you want to store the session’s state to persistent storage without finishing session processing for this request, call the update() method.
The caller can specify what form of storage to use for the session’s data with the database_manager option to CGI::Session::new. The following storage classes are provided as part of the standard library:
CGI::Session::FileStore
stores data as plain text in a flat file. Only works with String data. This is the default storage type.
CGI::Session::MemoryStore
stores data in an in-memory hash. The data only persists for as long as the current Ruby interpreter instance does.
CGI::Session::PStore
stores data in Marshalled format. Provided by cgi/session/pstore.rb. Supports data of any type, and provides file-locking and transaction support.
Custom storage types can also be created by defining a class with the following methods:
new(session, options) restore # returns hash of session data. update close delete
Changing storage type mid-session does not work. Note in particular that by default the FileStore and PStore session data files have the same name. If your application switches from one to the other without making sure that filenames will be different and clients still have old sessions lying around in cookies, then things will break nastily!
Most session state is maintained on the server. However, a session id must be passed backwards and forwards between client and server to maintain a reference to this session state.
The simplest way to do this is via cookies. The CGI::Session class provides transparent support for session id communication via cookies if the client has cookies enabled.
If the client has cookies disabled, the session id must be included as a parameter of all requests sent by the client to the server. The CGI::Session class in conjunction with the CGI class will transparently add the session id as a hidden input field to all forms generated using the CGI#form() HTML generation method. No built-in support is provided for other mechanisms, such as URL re-writing. The caller is responsible for extracting the session id from the session_id attribute and manually encoding it in URLs and adding it as a hidden input to HTML forms created by other mechanisms. Also, session expiry is not automatically handled.
require 'cgi' require 'cgi/session' require 'cgi/session/pstore' # provides CGI::Session::PStore cgi = CGI.new("html4") session = CGI::Session.new(cgi, 'database_manager' => CGI::Session::PStore, # use PStore 'session_key' => '_rb_sess_id', # custom session key 'session_expires' => Time.now + 30 * 60, # 30 minute timeout 'prefix' => 'pstore_sid_') # PStore option if cgi.has_key?('user_name') and cgi['user_name'] != '' # coerce to String: cgi[] returns the # string-like CGI::QueryExtension::Value session['user_name'] = cgi['user_name'].to_s elsif !session['user_name'] session['user_name'] = "guest" end session.close
require 'cgi' require 'cgi/session' cgi = CGI.new("html4") # We make sure to delete an old session if one exists, # not just to free resources, but to prevent the session # from being maliciously hijacked later on. begin session = CGI::Session.new(cgi, 'new_session' => false) session.delete rescue ArgumentError # if no old session end session = CGI::Session.new(cgi, 'new_session' => true) session.close
The error thrown when the parser encounters invalid encoding in CSV.
A custom InputMethod class used by XMP for evaluating string io.
Parent class for informational (1xx) HTTP response classes.
An informational response indicates that the request was received and understood.
References:
Response class for Switching Protocol responses (status code 101).
The <tt>Switching Protocol<tt> response indicates that the server has received a request to switch protocols, and has agreed to do so.
References:
Response class for Multi-Status (WebDAV) responses (status code 207).
The Multi-Status (WebDAV) response indicates that the server has received the request, and that the message body can contain a number of separate response codes.
References:
Response class for Gone responses (status code 410).
The resource requested was previously in use but is no longer available and will not be available again.
References:
Response class for URI Too Long responses (status code 414).
The URI provided was too long for the server to process.
References:
Response class for Unsupported Media Type responses (status code 415).
The request entity has a media type which the server or resource does not support.
References: