Comments (11)
I read RFCs, and this things is important for us:
- We should use
application/xml
instead oftext/xml
inContent-Type
header insideclient.propfind()
method:
rs, err := c.req("PROPFIND", path, strings.NewReader(body), func(rq *http.Request) {
if self {
rq.Header.Add("Depth", "0")
} else {
rq.Header.Add("Depth", "1")
}
rq.Header.Add("Content-Type", "text/xml;charset=UTF-8")
rq.Header.Add("Accept", "application/xml,text/xml")
rq.Header.Add("Accept-Charset", "utf-8")
// TODO add support for 'gzip,deflate;q=0.8,q=0.7'
rq.Header.Add("Accept-Encoding", "")
})
because text/xml
is deprecated (RFC4918):
When XML is used for a request or response body, the Content-Type type SHOULD be application/xml. Implementations MUST accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.
- We must not support Basic authentication method (RFC4918):
Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
- All information about "Clients desiring to Authenticate" located in Appendix E of RFC2918:
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
I propose to create client.Connect()
method, and use the second approach from Appendix E inside it:
The second approach is to use an Authorization header (defined in [RFC2617]), which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials.
from gowebdav.
@MrVine wrote:
We must not support Basic authentication method (RFC4918)
That makes no sense for a client library. The RFC states that servers must not present a Basic challenge, unless they're served over a secure connection (ie - TLS). I'd suggest that Basic auth is very widely implemented, as generally connections will be TLS encrypted. I'd be very concerned about any authentication over insecure channels, as leaking bearer tokens or other form of auth is frequently just as bad as leaking a username/password. In fact, Basic auth must be supported, for servers that only support it, and it's likely the only globally supported mechanism.
I propose to ... use the second approach from Appendix E inside it
I see very little value in complicating the auth mechanism in this direction, based on the above, and also based on the caveats listed in the RFC.
from gowebdav.
Good points. We'd have to add a check on each of [ReadDir, Stat, et. al.]. Maybe add a function to do the checking, initialize auth, and call the calling function again, passed as a parameter? With this approach there will be more code that unnecessarily runs twice.
from gowebdav.
If I correctly understand you, @chuckwagoncomputing , you suggest to add a check on each of [ReadDir, Stat, etc] functions?
Instead, I want to suggest to create new function which will do the checking and initialize auth, and call it directly from req()
function. This function will improve readability of req()
to help us to keep the request as small as possible.
What do you think about it?
from gowebdav.
From the standpoint of "seperation of concerns", that's essentially what I've done. @chripo's suggestion is that the checking should be the job of the Client part of the library, rather than the Requests part.
from gowebdav.
Thanks for explanation. Unfortunately I have no ideas how we can deal with this.
from gowebdav.
Further complicating this is the approach I created of duplicating the body in case it needs to be used again. I am ashamed of what I have done but I'm not sure how else to do it. If we do some redesigning, both of these things need to be considered.
from gowebdav.
@chripo , to remove TeeReader
from req()
method we should perform auth checking in separate method. For example, I propose to return c.Connect()
method, but use PROPFIND instead of OPTIONS.
from gowebdav.
From my point of view, sending the body twice is a total waste of performance and time.
Adding a strategy for auth would cleanup the code. I worked already on it, but unfinished,i'll share my code soon.
I think there is a way to send the first 6request without a body, need time for a deeper look into the specs / rfcs.
from gowebdav.
I haven't actually read the RFCs, but I know some clients do not send the body the first time. SabreDAV has a bug and won't authenticate with an empty body. The maintainer refused to fix it because he claimed it was non-standard to send the first packet without a body. It does have a workaround though.
from gowebdav.
@chripo, have you got anywhere with this?
from gowebdav.
Related Issues (20)
- Wrong content of uploaded file
- Www-Authenticate header's token should be treated as case-insensitive HOT 3
- File upload uploads files with 0 bytes - No error given HOT 9
- panic due to concurrent map writes HOT 8
- improve concurrency
- ReadDir omits returning the first result if it is a directory HOT 1
- Error on Folders with '+' HOT 3
- 400 when passing whitespace in path args to c.Copy()
- Set GetBody on http.Request HOT 2
- support Walk func HOT 1
- [err:WriteStream] file write problem: err:WriteStream HOT 2
- No support for Bearer Token authentication HOT 2
- [WIP] Supports upload files via WriteCloser
- Support for cookies HOT 3
- Authentication fails when deployed to Windows machine without Go installed HOT 4
- This is a library usage question,about ContentType. HOT 1
- [BUG/FEATURE] OneDrive Support HOT 2
- Digest auth usage HOT 2
- Use the tag Management release version to publish HOT 2
- Stat() for directory does not return last modified time HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gowebdav.