Lecture 1: Introduction to Research — [📝Lecture Notebooks] [
Lecture 2: Introduction to Python — [📝Lecture Notebooks] [
Lecture 3: Introduction to NumPy — [📝Lecture Notebooks] [
Lecture 4: Introduction to pandas — [📝Lecture Notebooks] [
Lecture 5: Plotting Data — [📝Lecture Notebooks] [[
Remote Code Execution via File Upload (CVE-2020-12255) | |
The rConfig 3.9.4 is vulnerable to remote code execution due to improper checks/validation via the file upload functionality. | |
The vendor.crud.php accepts the file upload by checking through content-type and it is not restricting upload by checking the file extension and header. | |
Due to this flaw, An attacker can exploit this vulnerability by uploading a PHP file that contains arbitrary code (shell) and changing the content-type to `image/gif` in the vendor.crud.php. | |
since the validation checks are happening through content-type the server would accept the PHP file uploaded ultimately resulting code execution upon the response when invoked. | |
Steps To Reproduce-: |
How to configure your Mac to use DNS over TLS in five easy steps:
-
Install Stubby with Homebrew (https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby):
brew install stubby
-
Edit the configuration file:
When used from the command line, the xmllint tool doesn't accept namespaces in xpath expressions. This makes it difficult to process XML documents like the one below (file demo.xml):
<?xml version="1.0" standalone="yes"?>
<svrl:schematron-output xmlns:svrl="http://purl.oclc.org/dsdl/svrl" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:schold="http://www.ascc.net/xml/schematron" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns:iso="http://purl.oclc.org
require 'test/unit' | |
class Queue | |
include Enumerable | |
Node = Struct.new :element, :next | |
attr_reader :head, :tail, :size | |
def initialize(items = []) |
This document is a collection of concepts and strategies to make large Elm projects modular and extensible.
We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp
. You will probably merge
a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:
- There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo
## | |
## Prefer mongodump/mongorestore instead of mongoexport/mongoimport, | |
## as it will "export" additional metadata, like indexes etc. | |
## | |
### Mongodump example | |
# Required: host, db, collection, out | |
# Optional: query (limit results) | |
mongodump --host mongodb1.example.net \ |
# Original Rails controller and action | |
class EmployeesController < ApplicationController | |
def create | |
@employee = Employee.new(employee_params) | |
if @employee.save | |
redirect_to @employee, notice: "Employee #{@employee.name} created" | |
else | |
render :new | |
end |
import asyncio | |
import aiohttp | |
import bs4 | |
import tqdm | |
@asyncio.coroutine | |
def get(*args, **kwargs): | |
response = yield from aiohttp.request('GET', *args, **kwargs) | |
return (yield from response.read_and_close(decode=True)) |