/ 
UR-0.47
River stage one • 2 direct dependents • 3 total dependents
⭐ Starred 3 GitHub stars
/ UR::DataSource::File
Security Advisories (11)
CVE-2018-14041 (2018-07-13)

In Bootstrap before 4.1.2, XSS is possible in the data-target property of scrollspy.

CVE-2018-14042 (2018-07-13)

In Bootstrap before 4.1.2, XSS is possible in the data-container property of tooltip.

CVE-2020-11022 (2020-04-29)

In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2020-11023 (2020-04-29)

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2019-11358 (2019-04-20)

jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.

CVE-2015-9251 (2018-01-18)

jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.

CVE-2011-4969 (2013-03-08)

Cross-site scripting (XSS) vulnerability in jQuery before 1.6.3, when using location.hash to select elements, allows remote attackers to inject arbitrary web script or HTML via a crafted tag.

CVE-2012-6708 (2018-01-18)

jQuery before 1.9.0 is vulnerable to Cross-site Scripting (XSS) attacks. The jQuery(strInput) function does not differentiate selectors from HTML in a reliable fashion. In vulnerable versions, jQuery determined whether the input was HTML by looking for the '<' character anywhere in the string, giving attackers more flexibility when attempting to construct a malicious payload. In fixed versions, jQuery only deems the input to be HTML if it explicitly starts with the '<' character, limiting exploitability only to attackers who can control the beginning of a string, which is far less common.

CVE-2020-7656 (2020-05-19)

jquery prior to 1.9.0 allows Cross-site Scripting attacks via the load method. The load method fails to recognize and remove "<script>" HTML tags that contain a whitespace character, i.e: "</script >", which results in the enclosed script logic to be executed.

CVE-2019-5428

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as _proto_, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

CVE-2014-6071 (2018-01-16)

jQuery 1.4.2 allows remote attackers to conduct cross-site scripting (XSS) attacks via vectors related to use of the text method inside after.

NAME

UR::DataSource::File - Parent class for file-based data sources

DEPRECATED

This module is deprecated. Use UR::DataSource::Filesystem instead.

SYNOPSIS

package MyNamespace::DataSource::MyFile;
class MyNamespace::DataSource::MyFile {
    is => ['UR::DataSource::File', 'UR::Singleton'],
};
sub server { '/path/to/file' }
sub delimiter { "\t" }
sub column_order { ['thing_id', 'thing_name', 'thing_color' ] }
sub sort_order { ['thing_id'] }

package main;
class MyNamespace::Thing {
    id_by => 'thing_id',
    has => [ 'thing_id', 'thing_name', 'thing_color' ],
    data_source => 'MyNamespace::DataSource::MyFile',
}
my @objs = MyNamespace::Thing->get(thing_name => 'Bob');

DESCRIPTION

Classes which wish to retrieve their data from a regular file can use a UR::DataSource::File-based data source. The modules implementing these data sources live under the DataSource subdirectory of the application's Namespace, by convention. Besides defining a class for your data source inheriting from UR::DataSource::File, it should have the following methods, either as properties or functions in the package.

Configuration

These methods determine the configuration for your data source.

server()

server() should return a string representing the pathname of the file where the data is stored.

file_list()

The file_list() method should return a listref of pathnames to one or more identical files where data is stored. Use file_list() instead of server() when you want to load-balance several NFS servers, for example.

You must have either server() or file_list() in your module, but not both. The existence of server() takes precedence over file_list().

delimiter()

delimiter() should return a string representing how the fields in each record are split into columns. This string is interpreted as a regex internally. The default delimiter is "\s*,\s*" meaning that the file is separated by commas.

record_separator()

record_separator() should return a string that gets stored in $/ before getline() is called on the file's filehandle. The default record_separator() is "\n" meaning that the file's records are separated by newlines.

skip_first_line()

skip_first_line() should return a boolean value. If true, the first line of the file is ignored, for example if the first line defines the columns in the file.

column_order()

column_order() should return a listref of column names in the file. column_order is required; there is no default.

sort_order()

If the data file is sorted in some way, sort_order() should return a listref of column names (which must exist in column_order()) by which the file is sorted. This gives the system a hint about how the file is structured, and is able to make shortcuts when reading the file to speed up data access. The default is to assume the file is not sorted.

INHERITANCE

UR::DataSource

SEE ALSO

UR, UR::DataSource