DOCSLIB.ORG

Aiohttp Documentation Release 3.7.4.Post0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Aiohttp Documentation Release 3.7.4.Post0 aiohttp Documentation Release 3.7.4.post0 aiohttp contributors Mar 06, 2021 CONTENTS 1 Key Features 3 2 Library Installation 5 2.1 Installing speedups altogether......................................5 3 Getting Started 7 3.1 Client example..............................................7 3.2 Server example:.............................................7 4 What’s new in aiohttp 3? 9 5 Tutorial 11 6 Source code 13 7 Dependencies 15 8 Communication channels 17 9 Contributing 19 10 Authors and License 21 11 Policy for Backward Incompatible Changes 23 12 Table Of Contents 25 12.1 Client................................................... 25 12.2 Server................................................... 79 12.3 Utilities.................................................. 162 12.4 FAQ.................................................... 177 12.5 Miscellaneous.............................................. 184 12.6 Who uses aiohttp?............................................ 246 12.7 Contributing............................................... 250 Python Module Index 255 Index 257 i ii aiohttp Documentation, Release 3.7.4.post0 Asynchronous HTTP Client/Server for asyncio and Python. Current version is 3.7.4.post0. CONTENTS 1 aiohttp Documentation, Release 3.7.4.post0 2 CONTENTS CHAPTER ONE KEY FEATURES • Supports both Client and HTTP Server. • Supports both Server WebSockets and Client WebSockets out-of-the-box without the Callback Hell. • Web-server has Middlewares, Signals and plugable routing. 3 aiohttp Documentation, Release 3.7.4.post0 4 Chapter 1. Key Features CHAPTER TWO LIBRARY INSTALLATION $ pip install aiohttp You may want to install optional cchardet library as faster replacement for chardet: $ pip install cchardet For speeding up DNS resolving by client API you may install aiodns as well. This option is highly recommended: $ pip install aiodns 2.1 Installing speedups altogether The following will get you aiohttp along with chardet, aiodns and brotlipy in one bundle. No need to type separate commands anymore! $ pip install aiohttp[speedups] 5 aiohttp Documentation, Release 3.7.4.post0 6 Chapter 2. Library Installation CHAPTER THREE GETTING STARTED 3.1 Client example import aiohttp import asyncio async def main(): async with aiohttp.ClientSession() as session: async with session.get('http://python.org') as response: print("Status:", response.status) print("Content-type:", response.headers['content-type']) html= await response.text() print("Body:", html[:15],"...") loop= asyncio.get_event_loop() loop.run_until_complete(main()) This prints: Status: 200 Content-type: text/html; charset=utf-8 Body: <!doctype html> ... Coming from requests ? Read why we need so many lines. 3.2 Server example: from aiohttp import web async def handle(request): name= request.match_info.get('name',"Anonymous") text="Hello,"+ name return web.Response(text=text) app= web.Application() app.add_routes([web.get('/', handle), web.get('/{name}', handle)]) (continues on next page) 7 aiohttp Documentation, Release 3.7.4.post0 (continued from previous page) if __name__ =='__main__': web.run_app(app) For more information please visit Client and Server pages. 8 Chapter 3. Getting Started CHAPTER FOUR WHAT’S NEW IN AIOHTTP 3? Go to What’s new in aiohttp 3.0 page for aiohttp 3.0 major release changes. 9 aiohttp Documentation, Release 3.7.4.post0 10 Chapter 4. What’s new in aiohttp 3? CHAPTER FIVE TUTORIAL Polls tutorial 11 aiohttp Documentation, Release 3.7.4.post0 12 Chapter 5. Tutorial CHAPTER SIX SOURCE CODE The project is hosted on GitHub Please feel free to file an issue on the bug tracker if you have found a bug or have some suggestion in order to improve the library. The library uses Azure Pipelines for Continuous Integration. 13 aiohttp Documentation, Release 3.7.4.post0 14 Chapter 6. Source code CHAPTER SEVEN DEPENDENCIES • Python 3.6+ • async_timeout • attrs • chardet • multidict • yarl • Optional cchardet as faster replacement for chardet. Install it explicitly via: $ pip install cchardet • Optional aiodns for fast DNS resolving. The library is highly recommended. $ pip install aiodns 15 aiohttp Documentation, Release 3.7.4.post0 16 Chapter 7. Dependencies CHAPTER EIGHT COMMUNICATION CHANNELS aio-libs discourse group: https://aio-libs.discourse.group Feel free to post your questions and ideas here. gitter chat https://gitter.im/aio-libs/Lobby We support Stack Overflow. Please add aiohttp tag to your question there. 17 aiohttp Documentation, Release 3.7.4.post0 18 Chapter 8. Communication channels CHAPTER NINE CONTRIBUTING Please read the instructions for contributors before making a Pull Request. 19 aiohttp Documentation, Release 3.7.4.post0 20 Chapter 9. Contributing CHAPTER TEN AUTHORS AND LICENSE The aiohttp package is written mostly by Nikolay Kim and Andrew Svetlov. It’s Apache 2 licensed and freely available. Feel free to improve this package and send a pull request to GitHub. 21 aiohttp Documentation, Release 3.7.4.post0 22 Chapter 10. Authors and License CHAPTER ELEVEN POLICY FOR BACKWARD INCOMPATIBLE CHANGES aiohttp keeps backward compatibility. After deprecating some Public API (method, class, function argument, etc.) the library guaranties the usage of depre- cated API is still allowed at least for a year and half after publishing new release with deprecation. All deprecations are reflected in documentation and raises DeprecationWarning. Sometimes we are forced to break the own rule for sake of very strong reason. Most likely the reason is a critical bug which cannot be solved without major API change, but we are working hard for keeping these changes as rare as possible. 23 aiohttp Documentation, Release 3.7.4.post0 24 Chapter 11. Policy for Backward Incompatible Changes CHAPTER TWELVE TABLE OF CONTENTS 12.1 Client The page contains all information about aiohttp Client API: 12.1.1 Client Quickstart Eager to get started? This page gives a good introduction in how to get started with aiohttp client API. First, make sure that aiohttp is installed and up-to-date Let’s get started with some simple examples. Make a Request Begin by importing the aiohttp module, and asyncio: import aiohttp import asyncio Now, let’s try to get a web-page. For example let’s query http://httpbin.org/get: async def main(): async with aiohttp.ClientSession() as session: async with session.get('http://httpbin.org/get') as resp: print(resp.status) print(await resp.text()) loop= asyncio.get_event_loop() loop.run_until_complete(main()) Now, we have a ClientSession called session and a ClientResponse object called resp. We can get all the information we need from the response. The mandatory parameter of ClientSession.get() coroutine is an HTTP url (str or class:yarl.URL instance). In order to make an HTTP POST request use ClientSession.post() coroutine: session.post('http://httpbin.org/post', data=b'data') Other HTTP methods are available as well: 25 aiohttp Documentation, Release 3.7.4.post0 session.put('http://httpbin.org/put', data=b'data') session.delete('http://httpbin.org/delete') session.head('http://httpbin.org/get') session.options('http://httpbin.org/get') session.patch('http://httpbin.org/patch', data=b'data') Note: Don’t create a session per request. Most likely you need a session per application which performs all requests altogether. More complex cases may require a session per site, e.g. one for Github and other one for Facebook APIs. Anyway making a session for every request is a very bad idea. A session contains a connection pool inside. Connection reusage and keep-alives (both are on by default) may speed up total performance. A session context manager usage is not mandatory but await session.close() method should be called in this case, e.g.: session= aiohttp.ClientSession() async with session.get('...'): # ... await session.close() Passing Parameters In URLs You often want to send some sort of data in the URL’s query string. If you were constructing the URL by hand, this data would be given as key/value pairs in the URL after a question mark, e.g. httpbin.org/get?key=val. Requests allows you to provide these arguments as a dict, using the params keyword argument. As an example, if you wanted to pass key1=value1 and key2=value2 to httpbin.org/get, you would use the following code: params={'key1':'value1','key2':'value2'} async with session.get('http://httpbin.org/get', params=params) as resp: expect='http://httpbin.org/get?key1=value1&key2=value2' assert str(resp.url) == expect You can see that the URL has been correctly encoded by printing the URL. For sending data with multiple values for the same key MultiDict may be used; the library support nested lists ({'key': ['value1', 'value2']}) alternative as well. It is also possible to pass a list of 2 item tuples as parameters, in that case you can specify multiple values for each key: params=[('key','value1'), ('key','value2')] async with session.get('http://httpbin.org/get', params=params) as r: expect='http://httpbin.org/get?key=value2&key=value1' assert str(r.url) == expect You can also pass str content as param, but beware – content is not encoded by library. Note that + is not encoded: 26 Chapter 12. Table Of Contents aiohttp Documentation, Release 3.7.4.post0 async with session.get('http://httpbin.org/get', params='key=value+1') as r: assert str(r.url) =='http://httpbin.org/get?key=value+1' Note: aiohttp internally performs URL canonicalization before sending request. Canonicalization encodes host part by IDNA codec and applies requoting to path and query parts. For example URL('http://example.com//%30?a=%31')
Load more

Recommended publications
  • 5G; 5G System; Access and Mobility Management Services; Stage 3 (3GPP TS 29.518 Version 15.0.0 Release 15)
    ETSI TS 129 518 V15.0.0 (2018-09) TECHNICAL SPECIFICATION 5G; 5G System; Access and Mobility Management Services; Stage 3 (3GPP TS 29.518 version 15.0.0 Release 15) 3GPP TS 29.518 version 15.0.0 Release 15 1 ETSI TS 129 518 V15.0.0 (2018-09) Reference RTS/TSGC-0429518vf00 Keywords 5G ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Towards an Ontology of HTTP Interactions Mathieu Lirzin, Béatrice Markhoff
    Towards an ontology of HTTP interactions Mathieu Lirzin, Béatrice Markhoff To cite this version: Mathieu Lirzin, Béatrice Markhoff. Towards an ontology of HTTP interactions. [Research Report] Université de Tours - LIFAT. 2020. hal-02901879 HAL Id: hal-02901879 https://hal.archives-ouvertes.fr/hal-02901879 Submitted on 17 Jul 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Towards an ontology of HTTP interactions Mathieu Lirzin1;2[0000−0002−8366−1861] and B´eatriceMarkhoff2[0000−0002−5171−8499] 1 N´er´eide,8 rue des d´eport´es,37000 Tours, France [email protected] 2 LIFAT EA 6300, Universit´ede Tours, Tours, France [email protected] Abstract. Enterprise information systems have adopted Web-based foun- dations for exchanges between heterogeneous programmes. These programs provide and consume via Web APIs some resources identified by URIs, whose representations are transmitted via HTTP. Furthermore HTTP re- mains at the heart of all Web developments (Semantic Web, linked data, IoT...). Thus, situations where a program must be able to reason about HTTP interactions (request-response) are multiplying. This requires an explicit formal specification of a shared conceptualization of those inter- actions.
    [Show full text]
  • X41 D-SEC Gmbh Dennewartstr
    Browser Security White PAPER Final PAPER 2017-09-19 Markus VERVIER, Michele Orrù, Berend-Jan WEVER, Eric Sesterhenn X41 D-SEC GmbH Dennewartstr. 25-27 D-52068 Aachen Amtsgericht Aachen: HRB19989 Browser Security White PAPER Revision History Revision Date Change Editor 1 2017-04-18 Initial Document E. Sesterhenn 2 2017-04-28 Phase 1 M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 3 2017-05-19 Phase 2 M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 4 2017-05-25 Phase 3 M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 5 2017-06-05 First DrAFT M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 6 2017-06-26 Second DrAFT M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 7 2017-07-24 Final DrAFT M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 8 2017-08-25 Final PAPER M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER 9 2017-09-19 Public Release M. VERVIER, M. Orrù, E. Sesterhenn, B.-J. WEVER X41 D-SEC GmbH PAGE 1 OF 196 Contents 1 ExECUTIVE Summary 7 2 Methodology 10 3 Introduction 12 3.1 Google Chrome . 13 3.2 Microsoft Edge . 14 3.3 Microsoft Internet Explorer (IE) . 16 4 Attack Surface 18 4.1 Supported Standards . 18 4.1.1 WEB TECHNOLOGIES . 18 5 Organizational Security Aspects 21 5.1 Bug Bounties . 21 5.1.1 Google Chrome . 21 5.1.2 Microsoft Edge . 22 5.1.3 Internet Explorer . 22 5.2 Exploit Pricing . 22 5.2.1 ZERODIUM . 23 5.2.2 Pwn2Own .
    [Show full text]
  • Httpclient-Tutorial.Pdf
    HttpClient Tutorial Oleg Kalnichevski Jonathan Moore Jilles van Gurp Preface .................................................................................................................................... iv 1. HttpClient scope .......................................................................................................... iv 2. What HttpClient is NOT .............................................................................................. iv 1. Fundamentals ....................................................................................................................... 1 1.1. Request execution ...................................................................................................... 1 1.1.1. HTTP request .................................................................................................. 1 1.1.2. HTTP response ............................................................................................... 2 1.1.3. Working with message headers ........................................................................ 2 1.1.4. HTTP entity .................................................................................................... 3 1.1.5. Ensuring release of low level resources ............................................................ 5 1.1.6. Consuming entity content ................................................................................ 6 1.1.7. Producing entity content .................................................................................. 6 1.1.8. Response
    [Show full text]
  • Fortiadc Server Load Balance Script Deployment Guide
    FortiADC Server Load Balance Script Deployment Guide VERSION 5.2.0 FORTINET DOCUMENT LIBRARY http://docs.fortinet.com FORTINET VIDEO GUIDE http://video.fortinet.com FORTINET BLOG https://blog.fortinet.com CUSTOMER SERVICE & SUPPORT https://support.fortinet.com FORTIGATE COOKBOOK http://cookbook.fortinet.com FORTINET TRAINING SERVICES http://www.fortinet.com/training FORTIGUARD CENTER http://www.fortiguard.com END USER LICENSE AGREEMENT http://www.fortinet.com/doc/legal/EULA.pdf FEEDBACK Email: [email protected] Friday, December 28, 2018 FortiADC Link Load Balance Deployment Guide First Edition TABLE OF CONTENTS TABLE OF CONTENTS 3 Configuration Overview 4 Deployment –Content Routes Based on URI String 9 Introduction FortiADC SLB supports Lua scripts to perform actions that are not currently supported by the built-in feature set. Scripts enable you to use predefined script commands and variables to manipulate the HTTP request/response or select a content route. The multi-script support feature enables you to use multiple scripts by setting their sequence of execution. Here are FortiADC's predefined scripts and commands that you can copy and customize in the GUI/Server Load Balance/Scripting page. Configuration Overview The script used in the SLB/VS configuration that is triggered when the associated virtual server receives an HTTP request or response. Then, it does the programmed action. The events in which you can create them are shown as below: Event name Description RULE_INIT The event is used to initialize global or static variables used within a script. It is triggered when a script is added or modified, or when the device starts up, or when the software is restarted.
    [Show full text]
  • Identity Provider (IDP) Technical Specifications Version 1.3
    Identity & Authorization Management (I.AM) Identity Provider (IDP) Technical specifications Version 1.3 This document is provided to you free of charge by the eHealth platform Willebroekkaai 38 – 1000 Brussel 38, Quai de Willebroeck – 1000 Bruxelles All are free to circulate this document with reference to the URL source. Table of contents Table of contents .................................................................................................................................................... 2 1. Document management ........................................................................................................................ 4 1.1 Document history ................................................................................................................................... 4 2. Introduction ........................................................................................................................................... 5 2.1 Goal of the service ................................................................................................................................. 5 2.2 Identity ................................................................................................................................................... 5 2.3 Trust ....................................................................................................................................................... 6 2.3.1 Web SSO ................................................................................................................................................
    [Show full text]
  • Security Analysis of Real-Life Openid Connect Implementations
    Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations Lauritz Holtmann Master’s Thesis – September 30, 2020. Chair for Network and Data Security. Supervisor: Dr.-Ing. Christian Mainka Advisor: Prof. Dr. Jörg Schwenk Advisor: Dr.-Ing. Vladislav Mladenov Abstract OpenID Connect 1.0 is an authentication protocol that extends the OAuth 2.0 Au- thorization Framework. A typical OpenID Connect 1.0 setup involves three parties: an End-User who wants to sign-in at a service, the OpenID Provider that authenti- cates the End-User and a Relying Party that provides a service to the End-User. Im- plementing Single Sign-On protocols like OpenID Connect enables Service Providers to delegate authorization and authentication tasks to a dedicated third party. This decentralized scenario comes with flexibility for implementing entities and usability benefits for End-Users but also introduces new challenges regarding secure andre- liable authentication mechanisms. In this thesis, three novel variants of attacks on OpenID Connect implementations and two attacks on the OpenID Connect speci- fication are presented. Besides these novel attacks, four Identity Provider andfive Service Provider implementations are evaluated against a set of previously known attacks and requirements resulting from the specification and current security best practices. During the execution of the analysis, NodeJS implementations of the Identity Provider and Service Provider parts of the OpenID Connect specification were created, which are also introduced in this thesis. Finally, common vulnerability patterns observed within the set of OpenID Connect implementations are derived and recommendations for additions to the OpenID Connect security considerations are given.
    [Show full text]
  • Ts 129 503 V15.4.0 (2019-07)
    ETSI TS 129 503 V15.4.0 (2019-07) TECHNICAL SPECIFICATION 5G; 5G System; Unified Data Management Services; Stage 3 (3GPP TS 29.503 version 15.4.0 Release 15) 3GPP TS 29.503 version 15.4.0 Release 15 1 ETSI TS 129 503 V15.4.0 (2019-07) Reference RTS/TSGC-0429503vf40 Keywords 5G ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at www.etsi.org/deliver. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Development and Implementation of Secure Web Applications
    DEVELOPMENT AND IMPLEMENTATION OF SECURE WEB APPLICATIONS AUGUST 2011 Acknowledgements CPNI would like to acknowledge and thank Daniel Martin and NGS Secure for their help in the preparation of this document. Abstract This guide is intended for professional web application developers and technical project managers who want to understand the current threats and trends in the web application security realm, and ensure that the systems they are building will not expose their organisations to an excessive level of risk. Disclaimer: Reference to any specific commercial product, process or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by CPNI. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. To the fullest extent permitted by law, CPNI accepts no liability for any loss or damage (whether direct, indirect or consequential and including, but not limited to, loss of profits or anticipated profits, loss of data, business or goodwill) incurred by any person and howsoever caused arising from or connected with any error or omission in this document or from any person acting, omitting to act or refraining from acting upon, or otherwise using, the information contained in this document or its references. You should make your own judgment as regards use of this document and seek independent professional advice on your particular circumstances. Executive summary Document scope This document is a practical guide on how to design and implement secure web applications. Any such analysis must start with an understanding of the risks to which your application will be exposed.
    [Show full text]
  • Plone.Restapi Documentation Release 1.0A1
    plone.restapi Documentation Release 1.0a1 Plone Foundation Sep 26, 2019 Contents 1 Contents 1 2 Introduction 219 3 Documentation 221 4 Getting started 223 5 Installation 225 6 Contribute 227 7 Examples 229 8 Support 231 9 License 233 HTTP Routing Table 235 Index 237 i ii CHAPTER 1 Contents 1.1 Introduction API Browser Quick Guide It can make your life easier if you use some kind of API browser application to explore the API when diving into this documentation. • We recommend to use the free Postman browser plugin. • For easy onboarding take a look at our Explore the API using Postman Quick-Guide. A hypermedia API provides an entry point to the API, which contains hyperlinks the clients can follow. Just like a human user of a regular website, who knows the initial URL of a website and then follows hyperlinks to navigate through the site. This has the advantage that the client only needs to understand how to detect and follow links. The URLs (apart from the inital entry point) and other details of the API can change without breaking the client. The entry point to the Plone RESTful API is the portal root. The client can ask for a REST API response by setting the 'Accept' HTTP header to 'application/json': http GET /plone HTTP/1.1 Accept: application/json Authorization: Basic YWRtaW46c2VjcmV0 curl curl -i http://nohost/plone -H 'Accept: application/json' --user admin:secret httpie http http://nohost/plone Accept:application/json -a admin:secret 1 plone.restapi Documentation, Release 1.0a1 python-requests requests.get('http://nohost/plone', headers={ 'Accept':'application/json', }, auth=('admin','secret')) This uses so-called ‘content negotiation’ 1.1.1 Content Negotiation Content negotiation is a mechanism defined in the HTTP specification that makes it possible to serve different versions of a document (or more generally, a resource representation) at the same URI, so that user agents can specify which version fit their capabilities the best.
    [Show full text]
  • Lightweight Server Support for Browser-Based CSRF Protection
    Lightweight Server Support for Browser-Based CSRF Protection Alexei Czeskis Alexander Moshchuk University of Washington Microsoft Research [email protected] [email protected] Tadayoshi Kohno Helen J. Wang University of Washington Microsoft Research [email protected] [email protected] ABSTRACT and attach any existing cookies (or other ambient authority state) Cross-Site Request Forgery (CSRF) attacks are one of the top to the forged request to the victim site. If the web application threats on the web today. These attacks exploit ambient author- looks at the cookie or other state attached to an HTTP request as ity in browsers (e.g., cookies, HTTP authentication state), turning an indication of authorization, the application may be tricked into them into confused deputies and causing undesired side effects on performing an unwanted action. For example, when a user vis- vulnerable web sites. Existing defenses against CSRFs fall short in its bad.com, the displayed page may force the browser to make their coverage and/or ease of deployment. In this paper, we present requests to bank.com/transfer-funds (e.g., by including an image). a browser/server solution, Allowed Referrer Lists (ARLs), that ad- When making the request to bank.com, the user’s browser will at- dresses the root cause of CSRFs and removes ambient authority for tach any cookies it has stored for bank.com. If bank.com verifies participating web sites that want to be resilient to CSRF attacks. the request only via the attached cookies, it may erroneously exe- Our solution is easy for web sites to adopt and does not affect any cute the attacker’s bidding.
    [Show full text]
  • 6753 Commscope Category: Standards Track H
    Internet Engineering Task Force (IETF) J. Winterbottom Request for Comments: 6753 Commscope Category: Standards Track H. Tschofenig ISSN: 2070-1721 Nokia Siemens Networks H. Schulzrinne Columbia University M. Thomson Microsoft October 2012 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) Abstract This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6753. Winterbottom, et al. Standards Track [Page 1] RFC 6753 HELD Dereferencing October 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]