Validate and generate passwords using open source tools

This is the API documentation for Patrowl Engines usage.

PDF Blocks is a secure, reliable, and fast API to work with PDF documents. Actions include: Merge PDF documents, add or remove passwords, add watermarks, remove, extract, reverse, and rotate pages, and more.

PdfBroker.io is an api for creating pdf files from Xsl-Fo or Html and other useful pdf utilities.

# Introduction PDF Generator API allows you easily generate transactional PDF documents and reduce the development and support costs by enabling your users to create and manage their document templates using a browser-based drag-and-drop document editor. The PDF Generator API features a web API architecture, allowing you to code in the language of your choice. This API supports the JSON media type, and uses UTF-8 character encoding. You can find our previous API documentation page with references to Simple and Signature authentication [here](https://docs.pdfgeneratorapi.com/legacy). ## Base URL The base URL for all the API endpoints is `https://us1.pdfgeneratorapi.com/api/v3` For example * `https://us1.pdfgeneratorapi.com/api/v3/templates` * `https://us1.pdfgeneratorapi.com/api/v3/workspaces` * `https://us1.pdfgeneratorapi.com/api/v3/templates/123123` ## Editor PDF Generator API comes with a powerful drag & drop editor that allows to create any kind of document templates, from barcode labels to invoices, quotes and reports. You can find tutorials and videos from our [Support Portal](https://support.pdfgeneratorapi.com). * [Component specification](https://support.pdfgeneratorapi.com/en/category/components-1ffseaj/) * [Expression Language documentation](https://support.pdfgeneratorapi.com/en/category/expression-language-q203pa/) * [Frequently asked questions and answers](https://support.pdfgeneratorapi.com/en/category/qanda-1ov519d/) ## Definitions ### Organization Organization is a group of workspaces owned by your account. ### Workspace Workspace contains templates. Each workspace has access to their own templates and organization default templates. ### Master Workspace Master Workspace is the main/default workspace of your Organization. The Master Workspace identifier is the email you signed up with. ### Default Template Default template is a template that is available for all workspaces by default. You can set the template access type under Page Setup. If template has "Organization" access then your users can use them from the "New" menu in the Editor. ### Data Field Data Field is a placeholder for the specific data in your JSON data set. In this example JSON you can access the buyer name using Data Field `{paymentDetails::buyerName}`. The separator between depth levels is :: (two colons). When designing the template you don’t have to know every Data Field, our editor automatically extracts all the available fields from your data set and provides an easy way to insert them into the template. ``` { "documentNumber": 1, "paymentDetails": { "method": "Credit Card", "buyerName": "John Smith" }, "items": [ { "id": 1, "name": "Item one" } ] } ``` * * * * * # Authentication The PDF Generator API uses __JSON Web Tokens (JWT)__ to authenticate all API requests. These tokens offer a method to establish secure server-to-server authentication by transferring a compact JSON object with a signed payload of your account’s API Key and Secret. When authenticating to the PDF Generator API, a JWT should be generated uniquely by a __server-side application__ and included as a __Bearer Token__ in the header of each request. ## Legacy Simple and Signature authentication You can find our legacy documentation for Simple and Signature authentication [here](https://docs.pdfgeneratorapi.com/legacy). ## Accessing your API Key and Secret You can find your __API Key__ and __API Secret__ from the __Account Settings__ page after you login to PDF Generator API [here](https://pdfgeneratorapi.com/login). ## Creating a JWT JSON Web Tokens are composed of three sections: a header, a payload (containing a claim set), and a signature. The header and payload are JSON objects, which are serialized to UTF-8 bytes, then encoded using base64url encoding. The JWT's header, payload, and signature are concatenated with periods (.). As a result, a JWT typically takes the following form: ``` {Base64url encoded header}.{Base64url encoded payload}.{Base64url encoded signature} ``` We recommend and support libraries provided on [jwt.io](https://jwt.io/). While other libraries can create JWT, these recommended libraries are the most robust. ### Header Property `alg` defines which signing algorithm is being used. PDF Generator API users HS256. Property `typ` defines the type of token and it is always JWT. ``` { "alg": "HS256", "typ": "JWT" } ``` ### Payload The second part of the token is the payload, which contains the claims or the pieces of information being passed about the user and any metadata required. It is mandatory to specify the following claims: * issuer (`iss`): Your API key * subject (`sub`): Workspace identifier * expiration time (`exp`): Timestamp (unix epoch time) until the token is valid. It is highly recommended to set the exp timestamp for a short period, i.e. a matter of seconds. This way, if a token is intercepted or shared, the token will only be valid for a short period of time. ``` { "iss": "ad54aaff89ffdfeff178bb8a8f359b29fcb20edb56250b9f584aa2cb0162ed4a", "sub": "demo.example@actualreports.com", "exp": 1586112639 } ``` ### Signature To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is. ``` HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), API_SECRET) ``` ### Putting all together The output is three Base64-URL strings separated by dots. The following shows a JWT that has the previous header and payload encoded, and it is signed with a secret. ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJhZDU0YWFmZjg5ZmZkZmVmZjE3OGJiOGE4ZjM1OWIyOWZjYjIwZWRiNTYyNTBiOWY1ODRhYTJjYjAxNjJlZDRhIiwic3ViIjoiZGVtby5leGFtcGxlQGFjdHVhbHJlcG9ydHMuY29tIn0.SxO-H7UYYYsclS8RGWO1qf0z1cB1m73wF9FLl9RCc1Q // Base64 encoded header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 // Base64 encoded payload: eyJpc3MiOiJhZDU0YWFmZjg5ZmZkZmVmZjE3OGJiOGE4ZjM1OWIyOWZjYjIwZWRiNTYyNTBiOWY1ODRhYTJjYjAxNjJlZDRhIiwic3ViIjoiZGVtby5leGFtcGxlQGFjdHVhbHJlcG9ydHMuY29tIn0 // Signature: SxO-H7UYYYsclS8RGWO1qf0z1cB1m73wF9FLl9RCc1Q ``` ## Testing with JWTs You can create a temporary token in [Account Settings](https://pdfgeneratorapi.com/account/organization) page after you login to PDF Generator API. The generated token uses your email address as the subject (`sub`) value and is valid for __5 minutes__. You can also use [jwt.io](https://jwt.io/) to generate test tokens for your API calls. These test tokens should never be used in production applications. * * * * * # Libraries and SDKs ## Postman Collection We have created a [Postman](https://www.postman.com) Collection so you can easily test all the API endpoints wihtout developing and code. You can download the collection [here](https://app.getpostman.com/run-collection/329f09618ec8a957dbc4) or just click the button below. [](https://app.getpostman.com/run-collection/329f09618ec8a957dbc4) ## Client Libraries All our Client Libraries are auto-generated using [OpenAPI Generator](https://openapi-generator.tech/) which uses the OpenAPI v3 specification to automatically generate a client library in specific programming language. * [PHP Client](https://github.com/pdfgeneratorapi/php-client) * [Java Client](https://github.com/pdfgeneratorapi/java-client) * [Ruby Client](https://github.com/pdfgeneratorapi/ruby-client) * [Python Client](https://github.com/pdfgeneratorapi/python-client) * [Javascript Client](https://github.com/pdfgeneratorapi/javascript-client) We have validated the generated libraries, but let us know if you find any anomalies in the client code. * * * * * # Error codes | Code | Description | |--------|--------------------------------| | 401 | Unauthorized | | 403 | Forbidden | | 404 | Not Found | | 422 | Unprocessable Entity | | 500 | Internal Server Error | ## 401 - Unauthorized | Description | |-------------------------------------------------------------------------| | Authentication failed: request expired | | Authentication failed: workspace missing | | Authentication failed: key missing | | Authentication failed: property 'iss' (issuer) missing in JWT | | Authentication failed: property 'sub' (subject) missing in JWT | | Authentication failed: property 'exp' (expiration time) missing in JWT | | Authentication failed: incorrect signature | ## 403 - Forbidden | Description | |-------------------------------------------------------------------------| | Your account has exceeded the monthly document generation limit. | | Access not granted: You cannot delete master workspace via API | | Access not granted: Template is not accessible by this organization | | Your session has expired, please close and reopen the editor. | ## 404 Entity not found | Description | |-------------------------------------------------------------------------| | Entity not found | | Resource not found | | None of the templates is available for the workspace. | ## 422 Unprocessable Entity | Description | |-------------------------------------------------------------------------| | Unable to parse JSON, please check formatting | | Required parameter missing | | Required parameter missing: template definition not defined | | Required parameter missing: template not defined |

Self Service Developer API documentation and demo. ##Getting Started You will need an API access profile user and password in order to access search endpoints. Your access profile user and password is used for authenticating all requests to our search API. You MUST pass the user and password each time you perform a search request.

Personio Authentication API

API for reading and writing personnel data incl. data about attendances and absences

This data set contains the list of polling places. It can be organized by ward/division, accessibility rating, or type of building. This list is used to assign poll workers, send the machines and necessary accessibility materials, etc. **Endpoint:** http://api.phila.gov/polling-places/v1

This api converts file formats of OpenXml and OpenOffice documents formats to vector files (e.g., svg)

This API helps users convert Excel and Powerpoint documents into rich, live dashboards and stories.

This API is the main entry point for creating, editing and publishing analytics throught the Presalytics API

Probely is a Web Vulnerability Scanning suite for Agile Teams. It provides continuous scanning of your Web Applications and lets you efficiently manage the lifecycle of the vulnerabilities found, in a sleek and intuitive ~~web interface~~ API. ## Quick-Start ### Authentication To use the API, you first need to create a token (API Key). To create a token, select a target from the drop-down list, go to the "Settings" page, and click on the "Integrations" tab. Write a name for the API Key. For example, if you want to use the API Key for travis, you could name it "travis". In this example, we chose "**example.com_key**" ![Creating API key][1] [1]: assets/qs/create_api_key_1.png The API key was created successfully: ![API key created][2] [2]: assets/qs/create_api_key_2.png On every request, you need to pass this token in the authorization header, like this: ```yaml Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJBRlNJQlp 3elFsMDEiLCJ1c2VybmFtZSI6IkNIZ2tkSUROdzV0NSJ9.90UwiPGS2hlvgOLktFU0LfKuatNKm mEP79u17VnqT9M ``` **WARNING: Treat this token as a password. With this token, you have the power to fully manage the target.** In the following examples, the token will be named as *PROBELY_AUTH_TOKEN*. ### Scan target First let's view our target list: ```bash curl https://api.probely.com/targets/ \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` From the results, we need the **target id**: ```json { "count":1, "page_total":1, "page":1, "length":10, "results":[ { "id":"AxtkqTE0v3E-", "name":"test-site", "desc":"", "url":"https://test-site.example.com", "settings": "(...)" , "stack": "(...)" , "verified":true, "(...)": "(...)" } ] } ``` Now we can send a request to start a scan on target id **AxtkqTE0v3E-** ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/scan_now/ \ -X POST \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` And we get a response saying that the scan is scheduled: the status is **queued**, and we've got a **scan id**: ```json { "changed":"2017-08-01T13:37:00.843339Z", "started":null, "completed":null, "mediums":0, "changed_by": "(...)" , "highs":0, "status":"queued", "id":"S6dOMPn0SnoH", "created_by": "(...)" , "target": "(...)" , "created":"2017-08-01T13:37:00.843339Z", "lows":0 } ``` Using the scan id **S6dOMPn0SnoH**, we can pool the scan status: ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/scans/S6dOMPn0SnoH/ \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` And we get a response saying that the scan status is now **started**: ```json { "id":"S6dOMPn0SnoH", "changed":"2017-08-01T13:38:12.623650Z", "started":null, "completed":null, "mediums":0, "changed_by": "(...)" , "highs":0, "status":"started", "created_by": "(...)" , "target": "(...)" , "created":"2017-08-01T13:37:00.843339Z", "lows":0 } ``` The possible statuses are: | Status | Name | Description | | ------ | ---- | ----------- | | queued | Queued | The scan is queued to start | | started | Started | The scan is currently running | | under_review | Under Review | The scan is complete but has some findings under review | | completed | Completed | The scan is complete | | completed_with_errors | Completed with errors | The scan is complete even after getting some error(s) | | failed | Failed | The scan failed | | canceled | Canceled | The scan was canceled | | canceling | Canceling | The scan is being canceled | During the scan, the keys "lows", "mediums", and "highs" will be updated with the findings, as they are being found. After we get either the status **completed** or **completed_with_errors**, we can view the findings. ### Get vulnerabilities Using the previous scan id **S6dOMPn0SnoH**, we can get the scan results: ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/scans/S6dOMPn0SnoH/ \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` We get a response saying that the scan status is now **completed**, and that **45** vulnerabilities were found. **14** low, **11** medium and **20** high: ```json { "id":"S6dOMPn0SnoH", "target": "(...)" , "status":"completed", "started":"2017-08-01T13:37:12.623650Z", "completed":"2017-08-01T14:17:48.559514Z", "lows":14, "mediums":11, "highs":20, "created":"2017-08-01T13:37:00.843339Z", "created_by": "(...)" , "changed":"2017-08-01T14:17:48.559514Z", "changed_by": "(...)" } ``` You can now view the results of this scan, or the target findings. Let's start with the scan results: ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/findings/?scan=S6dOMPn0SnoH&page=1 \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` ```json { "count":45, "page_total":5, "page":1, "length":10, "results":[ { "id":79, "target": "(...)" , "scans": "(...)" , "labels": "(...)" , "fix":"To fix an SQL Injection in PHP, you should use Prepared Statements. Prepared Statements can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters.\n\nPHP's PDO extension supports Prepared Statements, so that's probably your best option.\n\nIn the example below you can see the use of prepared statements. Variables ```$username``` and ```$hashedPassword``` come from user input.\n\n```\n$stmt = $dbg->prepare(\"SELECT id, name FROM users\n WHERE username=? AND password=?\");\n$stmt->bindParam(1, $username);\n$stmt->bindParam(2, $hashedPassword);\nif ($stmt->execute()) {\n\t$user = $stmt->fetch();\n\tif ($user) {\n\t\t$_SESSION['authID'] = $user['id'];\n\t\techo \"Hello \" . $user['name'];\n\t} else {\n\t\techo \"Invalid Login\";\n\t}\n}\n``` \n\nAs an added bonus, if you're executing the same query several times, then it'll be even faster than when you're not using prepared statements. This is because when using prepared statements, the query needs to be parsed (prepared) only once, but can be executed multiple times with the same or different parameters. \n", "requests":[ { "request":"(...)", "response":"(...)" }, { "request":"(...)", "response":"(...)" } ], "evidence":null, "extra":"", "definition":{ "id":"xnV8PJVmSoLS", "name":"SQL Injection", "desc":"SQL Injections are the most common form of injections because SQL databases are very popular in dynamic web applications. This vulnerability allows an attacker to tamper existing SQL queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database.\n\nSince databases are commonly used to store private data, such as authentication information, personal user data and site content, if an attacker gains access to it, the consequences are typically very severe, ranging from defacement of the web application to users data leakage or loss, or even full control of the web application or database server.", }, "url":"http://test-site.example.com/login.php", "path":"login.php", "method":"post", "parameter":"username", "value":"", "params":{ "username":[ "probely'" ], "password":[ "probely" ] }, "reporter": "(...)" , "assignee":null, "state":"notfixed", "severity":30, "last_found":"2017-08-01T14:03:56.207794Z", "changed":"2017-08-01T14:03:56.207794Z", "changed_by": "(...)" , "comment":"" }, "(...)" ] } ``` You can also view all the target findings, which will show all the findings that are not yet fixed. \\ The structure is similar to the previous result. ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/findings/ \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` ### Get vulnerability details You can also get details for a particular finding in a target. \\ In this example we will get the details for the same finding as in the previous section: ```bash curl https://api.probely.com/targets/AxtkqTE0v3E-/findings/79/ \ -X GET \ -H "Content-Type: application/json" \ -H "Authorization: JWT PROBELY_AUTH_TOKEN" ``` This will result on the same information, but just for this particular finding: ```json { "id":79, "target": "(...)" , "scans": "(...)" , "labels": "(...)" , "fix":"To fix an SQL Injection in PHP, you should use Prepared Statements. Prepared Statements can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters.\n\nPHP's PDO extension supports Prepared Statements, so that's probably your best option.\n\nIn the example below you can see the use of prepared statements. Variables ```$username``` and ```$hashedPassword``` come from user input.\n\n```\n$stmt = $dbg->prepare(\"SELECT id, name FROM users\n WHERE username=? AND password=?\");\n$stmt->bindParam(1, $username);\n$stmt->bindParam(2, $hashedPassword);\nif ($stmt->execute()) {\n\t$user = $stmt->fetch();\n\tif ($user) {\n\t\t$_SESSION['authID'] = $user['id'];\n\t\techo \"Hello \" . $user['name'];\n\t} else {\n\t\techo \"Invalid Login\";\n\t}\n}\n``` \n\nAs an added bonus, if you're executing the same query several times, then it'll be even faster than when you're not using prepared statements. This is because when using prepared statements, the query needs to be parsed (prepared) only once, but can be executed multiple times with the same or different parameters. \n", "requests":[ { "request":"(...)", "response":"(...)" }, { "request":"(...)", "response":"(...)" } ], "evidence":null, "extra":"", "definition":{ "id":"xnV8PJVmSoLS", "name":"SQL Injection", "desc":"SQL Injections are the most common form of injections because SQL databases are very popular in dynamic web applications. This vulnerability allows an attacker to tamper existing SQL queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database.\n\nSince databases are commonly used to store private data, such as authentication information, personal user data and site content, if an attacker gains access to it, the consequences are typically very severe, ranging from defacement of the web application to users data leakage or loss, or even full control of the web application or database server.", }, "url":"http://test-site.example.com/login.php", "path":"login.php", "method":"post", "parameter":"username", "value":"", "params":{ "username":[ "probely'" ], "password":[ "probely" ] }, "reporter": "(...)" , "assignee":null, "state":"notfixed", "severity":30, "last_found":"2017-08-01T14:03:56.207794Z", "changed":"2017-08-01T14:03:56.207794Z", "changed_by": "(...)" , "comment":"" } ``` ## Concepts The short version is that you run *scans* on *targets*, and *findings* are created for any issue that is found. However, there are a few more concepts that must be explained in order to get a complete picture of how Probely works. We will spend the next few sections detailing the most important concepts. ### Target A *target* defines the scope of a scan, what will and won't be included in the scan plan. This is done by filling a *target*'s *site* and *assets*. The entry point for the web application (and authentication) is setup in the *target*'s *site*. In modern web applications, you are probably loading resources from multiple domains. A single page app, for example, will usualy load the page from one domain and make AJAX requests to another. This is what *assets* are for: they specify what domains our scanner should follow and create requests for. ### Site A URL is probably not the only thing you will need to setup when scannning your application. Does the application have an authenticated area? Does it use basic auth? Does it expect a certain cookie or header? These parameters are all configured in the *target*'s *site*. We need to ensure that only allowed web applications are scanned. Therefore, we must verify that you have control of any site you wish to include. This can be done by: * Placing a file on a well-known location, on the site's server; * Creating specific DNS records. ### Asset An *asset* is very similar to a *site*. The difference is that it is a domain instead of a URL. Additionally, an *asset* has no login or basic auth support. You can still have custom cookies and headers per *asset*. As with the *site*, you will need to prove an *asset*'s ownership. We have added some rules to make your life easier, if you already have verified a *site* and the domains match, the validation is fast-tracked. ### Scans This is what you're here for. After configuring your *target*, you will want to run *scans* against it. You can either start a one off scan, or schedule one for later - recurring or not. During the *scan*, we will spider and run several modules to check for security issues, which we call *findings*. You can check the *findings* even before a scan ends. If everything goes well, the scan will complete and that is it. With some *findings*, our automated processes may have difficulties determining if it is a false positive or a legitimate issue. In these instances, a scan will be marked as under review, and we will further analyze the finding before making a decision. We will only show findings that, for some degree of confidence, are true positives. A finding that we are not sure of will never be displayed. As much as we try to prevent it, a *scan* (or a sub-module) can malfunction. If this happens, a *scan* is marked as: * "failed": the problem was irrecoverable; * "completed with errors": some module failed but the scan itself completed. During a scan, we try to determine what *frameworks* you are using and add this information to the *site* and *asset* objects discussed previously. ### Findings The last core concept is the *finding*, this is a security issue that we have found during our scans. If the same issue is found in a new scan it will not open a new finding but update the previous. A *finding* will have a lot of information about the issue. Namely, where it was found, URL, insertion point (e.g. cookie), parameter, and method. Evidence we gathered, and the full request and response that we used. Sugestions of how to go about fixing it. A full description of the vulnerability is also present in the *definition* property. We also assign a severity and calculate the CVSS score for each. Besides all this, there are also actions that you can perform on a *finding*. You can assign it to one user, leave comments for your team or add labels, and reduce or increase the severity. If you don't plan on fixing the *finding* and accept the risk, or you think we reported a false positive, you can mark the finding to reflect that.

The PTV Timetable API provides direct access to Public Transport Victoria’s public transport timetable data. The API returns scheduled timetable, route and stop data for all metropolitan and regional train, tram and bus services in Victoria, including Night Network(Night Train and Night Tram data are included in metropolitan train and tram services data, respectively, whereas Night Bus is a separate route type). The API also returns real-time data for metropolitan train, tram and bus services (where this data is made available to PTV), as well as disruption information, stop facility information, and access to myki ticket outlet data. This Swagger is for Version 3 of the PTV Timetable API. By using this documentation you agree to comply with the licence and terms of service. Train timetable data is updated daily, while the remaining data is updated weekly, taking into account any planned timetable changes (for example, due to holidays or planned disruptions). The PTV timetable API is the same API used by PTV for its apps. To access the most up to date data PTV has (including real-time data) you must use the API dynamically. You can access the PTV Timetable API through a HTTP or HTTPS interface, as follows: base URL / version number / API name / query string The base URL is either: * http://timetableapi.ptv.vic.gov.au or * https://timetableapi.ptv.vic.gov.au The Swagger JSON file is available at http://timetableapi.ptv.vic.gov.au/swagger/docs/v3 Frequently asked questions are available on the PTV website at http://ptv.vic.gov.au/apifaq Links to the following information are also provided on the PTV website at http://ptv.vic.gov.au/ptv-timetable-api/ * How to register for an API key and calculate a signature * PTV Timetable API V2 to V3 Migration Guide * Documentation for Version 2 of the PTV Timetable API * PTV Timetable API Data Quality Statement All information about how to use the API is in this documentation. PTV cannot provide technical support for the API. Credits: This page has been based on Steve Bennett's http://opentransportdata.org/, used with permission.

Coronavirus API with free COVID-19 live updates. The best free coronavirus API and COVID-19 update source. Programmatically access live corona virus updates for statistics with historical data, maps, charts, graphs. COVID-19 API and corona virus live updates.