Re: [webkit-gtk] libwebkit2gtk and NTLM authentication
On 10/18/2013 02:55 AM, Carlos Garcia Campos wrote: > El jue, 17-10-2013 a las 14:44 -0400, Dan Winship escribió: >> Eventually libsoup will optionally support "Negotiate" (aka GSS-API aka >> Kerberos 5) authentication as well, so you might want to make the API a >> little bit generic. > > Good point, I actually thought about that, using a generic method that > receives a WebKitAuthenticationScheme[0], but then I thought that some > of the schemes should probably be always enabled, or is there any use > case where it makes sense to disable basic and digest, for example? I don't think it would ever make sense in a general-purpose web browser, but there might be other uses of WebKitGTK where it does? -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
Re: [webkit-gtk] libwebkit2gtk and NTLM authentication
On 10/17/2013 04:02 AM, Carlos Garcia Campos wrote: > So, I guess we need to expose API to allow the user enable this feature > as Brian suggested. I think adding a new method to WebKitWebContext > makes sense, because other global network options are handled this way > (cookies, icon database, security manager, cache model, disk cache, > etc.). Eventually libsoup will optionally support "Negotiate" (aka GSS-API aka Kerberos 5) authentication as well, so you might want to make the API a little bit generic. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
Re: [webkit-gtk] libwebkit2gtk and NTLM authentication
On 10/16/2013 05:38 AM, Carlos Garcia Campos wrote: > El mié, 16-10-2013 a las 12:18 +0300, Toni Koski escribió: >> I try to implement NTLM authentication with webkit2gtk (2.2.0). >> >> There can be found: "WEBKIT_AUTHENTICATION_SCHEME_NTLM = 5" from the >> WebKitAuthenticationScheme. >> However, I can't catch The "authenticate" -signal in case of NTLM. It >> seems to work fine at least with BASIC and DIGEST -authentications. > > According to libsoup API docs, NTLM authentication is not enabled by > default and the feature should be added to the session explicitly. I > don't think we are doing that in WebKit, so I guess we don't support > NTLM authentication at the moment. > > Dan, is this right? Yes. You need to do soup_session_add_feature_by_type (session, SOUP_TYPE_NTLM_AUTH); There are some arguments against enabling it by default; if you have the client-side samba stuff installed, and are logged into a Windows domain, then NTLM authentication can happen completely transparently (ie, no "authenticate" signal, no password dialog) using the cached credentials, and there are attacks against intranets that you could make using that functionality if you could hijack someone's http connection... so it's best to only have it get used when the app is explicitly expecting it to be used (as in evolution). -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
Re: [webkit-gtk] TLS API in WebKit2
On 06/20/2012 01:15 PM, Carlos Garcia Campos wrote: >>> - Set SOUP_SESSION_SSL_STRICT property. >> >> I think what you want is a signal basically like >> GTlsConnection::accept-certificate; WebKit would always be ssl-strict = >> FALSE internally, and when it got a response with a bad certificate, it >> would emit some signal to let the app decide whether or not to accept >> the response anyway. Or alternatively there could be an "always accept >> certs" property. Default should be to not do that though. > > hmm, the problem is that we can't stop the load until the certificate is > accepted. From the api point of view, it makes a lot of sense and maybe > we could even use the generic permission request api added by Mario. > So, I think we could do the opposite, set ssl-strict = TRUE internally, > and handle the ssl-error emitting the new signal (or permission-request > if we decide to use the generic permission request api) instead of > load-error. The problem with this approach is that if the certificate is > affected the next request will fail again because ssl-strict is TRUE. Right. That's why I was saying you should always be ssl-strict=FALSE internally. Then just check the tls-errors yourself, and from that point you can expose whatever behavior you want to the higher API layers. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] TLS API in WebKit2
On 06/20/2012 11:30 AM, Carlos Garcia Campos wrote: > As with the cookies, in WebKit2 we need to provide specific API for TLS > handling, because the network happens in the web process, and it's not > possible to access the soup session from the UI process. Right. So, SoupSession's TLS-related properties are a complete disaster, so you definitely don't want an API that looks anything like that. > We want to support at least: > > - Set SOUP_SESSION_SSL_STRICT property. I think what you want is a signal basically like GTlsConnection::accept-certificate; WebKit would always be ssl-strict = FALSE internally, and when it got a response with a bad certificate, it would emit some signal to let the app decide whether or not to accept the response anyway. Or alternatively there could be an "always accept certs" property. Default should be to not do that though. > - Set SOUP_SESSION_USE_SYSTEM_CA_FILE property > - Set SOUP_SESSION_TLS_DATABASE property You definitely want ssl-use-system-ca-file = TRUE by default. To support the tls-database property, you would have to write a GTlsDatabase implementation that proxied calls between the two processes. Then you could pass that tlsdb to libsoup in the network process, and have it talk to the tlsdb that the application gave you in the UI process. Since you presumably already have easy ways of communicating between the processes, this shouldn't be that hard. OTOH, I'm not really sure that letting the user provide their own tlsdb is really necessary, so maybe put this one off for now? (You'd also need to be careful in the proxy GTlsDatabase implementation that it can't end up blocking the network process while waiting for the UI process.) > or at least provide a file to create a database object from the file There's not really a whole lot of reason to create a database from a file other than the default system certdb, and if you did need to do that, you're just as likely to want to create it from a static string, or a GResource, or a GSetting value, etc. So I don't think we need to privilege file-based GTlsDatabases. > - Check SOUP_MESSAGE_CERTIFICATE_TRUSTED flag > - Provide further information in case of SSL error (GTlCertificateFlags > and GTlsCertificate) > - Provide access to the GTlsCertificate > > Am I missing anything? Client-side certificates, though of course, neither libsoup nor WebKit nor epiphany/midori/etc support that currently. It works vaguely like authentication though; the request would fail with G_TLS_ERROR_CERTIFICATE_REQUIRED, and the app would have to somehow select a GTlsCertificate and pass it to the network process. I think the answer here though is that we need to wait until the underlying APIs are there, and then fit them into WK2. > SOUP_MESSAGE_CERTIFICATE_TRUSTED flag could be exposed by > WebKitURIRequest and WebKitURIResponse APIs, something like > webkit_uri_response_is_certificate_trusted() or something similar. An enum would probably work better: there's plain http, https with an untrusted cert, https with a trusted cert, and https with an EV cert. (Anything else that we need to distinguish in the UI?) > It looks a bit weird having the certificate and the > flags in the view though Yeah, it does. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] NetworkRequest and NetworkResponse in WebKit2 API
On 11/15/2011 11:17 AM, Carlos Garcia Campos wrote: > The thing is that in WebKit2 we only have the information in the UI > process, the network stuff happens in the Web process Oh, right. So yeah, I agree that the second approach in your original mail (expose individual bits of data rather than the SoupMessage as a whole) is probably best then. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] NetworkRequest and NetworkResponse in WebKit2 API
On 11/15/2011 05:46 AM, Sergio Villar Senin wrote: > En 15/11/11 11:08, Carlos Garcia Campos escribiu: >> I'm currently working on downloads API for WebKit2 and I need to expose >> NetworkResponse which is not wrapped in WebKit2 API yet. In WebKit1 we >> have WebKitNetworkRequest and WebKitNetworkResponse, which are mostly >> the same because a SoupMessage represents both a request and response. >> So, both NetworkRequest and NetworkResponse are just a URI and a >> SoupMessage. Thinking about how to expose them in WebKit2 API several >> ideas came to my mind: > > In general I'd avoid exposing the SoupMessage basically because ideally > we will not need it in the future as it would become just an > implementation detail of the new libsoup stream API. I think SoupMessage will still be around... we need somewhere to store all the parsed information (headers, etc). (Although I guess we could just add methods to SoupRequestHTTP?) But anyway, SoupMessage only exists for HTTP anyway; you should expose the SoupRequest object instead so the API works for other types too. And if it's a SoupRequestHTTP then the caller can get the SoupMessage from that. (Maybe there could be a WebKitNetworkRequest/Response helper method to get the SoupMessage directly too I guess.) > SoupMessage returns a SoupURI > which is not so convenient to use, because you need to call > soup_uri_to_string() which returns a new allocated string. We could add "const char *soup_request_get_uri_as_string()" if that would be useful. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] WebKitGTK+ Release Policy and Schedule
On 09/26/2011 08:57 AM, Xan Lopez wrote: > So this is what you can expect in terms of releases: > > - One unstable, preview release, of WebKitGTK+ with each GNOME > unstable release until the UI freeze > > - A stable release, of the form 1.X+1.0 at the same time than the > GNOME stable release... and if you want exact dates, the current GNOME release schedule can always be found at http://www.gnome.org/start/unstable -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] What supposed to hold the GDK in calls from WebKit/gtk/WebCoreSupport
On 08/22/2011 02:26 PM, Evan Martin wrote: > On Mon, Aug 22, 2011 at 9:34 AM, Martin Robinson wrote: >> On Mon, Aug 22, 2011 at 9:26 AM, Yehouda Harpaz wrote: >>> The Soup callbacks happend form the g_main_loop_run by some idle >>> source, which is is establisg by Soup code itself, so to get this you >>> need to change the Soup source. Is that what you mean? >> >> No, since I do not believe that libsoup depends on GDK. We may need to >> change the libsoup backend in WebKit though. I'm just conjecturing at >> this point though. :) > > You can grab the gdk lock upon entry to the callbacks that you > register with libsoup. Just to confirm, this is exactly the right answer, and applies not just to libsoup, but to all main loop callbacks that don't arise out of gdk event processing. (Eg, gio async callbacks, glib idle handlers and timeouts, etc.). -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] 1.4.1 - CLOSE_WAIT
On 06/27/2011 12:30 PM, Marco Peereboom wrote: > Would merging these patches help? > https://bugs.webkit.org/show_bug.cgi?id=35721 > https://bugs.webkit.org/show_bug.cgi?id=35573 I was talking about HTTP connections. I have no idea how WebSockets connections are managed. (That happens inside WebKit.) -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] 1.4.1 - CLOSE_WAIT
On 06/24/2011 04:49 PM, David Hill wrote: > When using a browser with WebkitGTk 1.4.1, I get a lot of CLOSE_WAITs > sitting around. Does Webkit open up sockets itself, or does it solely > use libsoup to do the web connections? This is one of the leftover bits of historical lameness in libsoup. It doesn't pay attention to persistent connections when they're idle. So if the server times out a connection and closes it, it will show up in CLOSE_WAIT on the client for a while. Libsoup will only notice it when either you try to connect to that server again, or if it hits the maximum-number-of-open-connections limit. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] LibSoup issue blocking WebGL?
On 05/13/2011 09:19 PM, Won J Jeon wrote: > Hi all, > > > > ... Whenever GtkLauncher tries to load WebGL pages, it has "SSL handshake > failed" error. This probably means you don't have the glib-networking package installed (which contains the TLS implementations for GSocketConnection in gio). (If you have a more recent libsoup, it will (a) refuse to build if you don't have glib-networking installed, and (b) give a better error if you end up running it without glib-networking installed.) -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] dns prefetching knob
On 03/09/2011 07:55 AM, Marco Peereboom wrote: > For some reason > people are still attached to this relic of the modem era. DNS prefetch > is optional in the HTTP spec and the time has come to admit that it no > longer serves a purpose. Back in the day when modems were king and DNS > lookups were expensive you could save some time when a user clicked on a > link. Times have changes and the web has evolved. Prefetch isn't mentioned in the HTTP spec at all. And I don't think anyone was doing it back in the modem age. AFAIK, Google started doing it with Chrome, and other people followed. It *does* help in some cases. Lots of sites have lame slow DNS servers (and lots of ISPs have lame slow recursive resolvers). We just don't want to try to pre-resolve every single link on the page. -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] dns prefetching knob
On 03/08/2011 07:07 PM, Marco Peereboom wrote: > I created a bug report to add a DNS prefetch knob but I was advised to > also send the patch to the mailing list. > > With this knob I can make the web browser I wrote (xxxterm > http://opensource.conformal.com/wiki/XXXTerm ) much snappier on sites > with lots of embedded domain names (news.google.com for example). The entire point of DNS prefetching is that it's supposed to make the browser faster. If it's not doing that, then the right thing would be to remove it entirely, not to add a configurable "be broken / don't be broken" option. But I'm pretty sure the problem is just that we're prefetching too much: https://bugs.webkit.org/show_bug.cgi?id=41630. (Although I think it's gotten a little better since then. I don't see the spurious "no such host"s any more...) -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] HTTP disk-cache support in multiprocess environment, bug 44261
On 10/13/2010 04:46 AM, Sergio Villar Senin wrote: > Both of them will happen as you said. Those scenarios were not > considered during the development process. Take into account that the > http cache that is currently inside webkit is not meant to be there, > it's just a temporal fix while all this stuff does not land into > libsoup. So I don't think that there would be many situations like the > one you describe. Applications that will take advantage of that would be > mainly web browsers using webkitgtk, i.e, midori and epiphany. And, eg, epiphany puts its cache into ~/.cache/epiphany/, so no one else is going to end up using that cache accidentally. Having a shared multiprocess cache would definite be nice for some things, although you don't want to slow down access in the normal case to get it... Was there any particular use case you had, or just the general "it would be nice if different apps could share the same cached data"? -- Dan ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
