[webkit-gtk] TLS Errors API

[Brian Holt]

A new patch is up for review at
https://bugs.webkit.org/attachment.cgi?id=213777&action=review.

The idea is now that when the TLS policy is WEBKIT_TLS_ERRORS_POLICY_FAIL
and there is a TLS error, a new signal "load-failed-with-tls-errors" will be
emitted to notify the user of the error along with a WebKitCertificateInfo*
(boxed type) and the host (char*).

The WebKitCertificateInfo API is proposed as

    WEBKIT_API GType
    webkit_certificate_info_get_type (void);

    WEBKIT_API WebKitCertificateInfo *
    webkit_certificate_info_copy (WebKitCertificateInfo *info);

    WEBKIT_API void
    webkit_certificate_info_free (WebKitCertificateInfo *info);

    WEBKIT_API GTlsCertificate *
    webkit_certificate_info_get_tls_certificate (WebKitCertificateInfo
*info);

    WEBKIT_API GTlsCertificateFlags
    webkit_certificate_info_get_tls_errors (WebKitCertificateInfo *info);

If the user wishes the allow an exception for this certificate they can do
so with

    WEBKIT_API void
    webkit_web_context_allow_tls_certificate_for_host (WebKitWebContext
*context,
                                                       WebKitCertificateInfo
*info,
                                                       const gchar *host);

Any comments and feedback on the proposed API are welcome.

Regards
Brian


> -----Original Message-----
> From: webkit-gtk-bounces at lists.webkit.org [mailto:webkit-gtk-
> bounces at lists.webkit.org] On Behalf Of Brian Holt
> Sent: 04 October 2013 16:03
> To: webkit-gtk at lists.webkit.org
> Subject: Re: [webkit-gtk] TLS Errors API
> 
> The consensus on IRC #webkitgtk+ and the bug is that the permission-
> request model isn't a good fit for this particular issue, summarised by
> Gustavo:
> 
> > So, here's my opinion after understanding how this works: the
> permission request APIs we currently have are also in a way actions -
> when you allow a geolocation request webcore will go ahead and provide
> proceed with obtaining the location, when you deny it, webcore will
> tell the backend it's denied, and the content will be able to show an
> error. I think it would be bad to reuse these methods with such a
> different meaning and requiring the API user to take a second action
> after using them.
> 
> The current insecure-content-detected notification is probably a better
> approach to follow, so I'm proposing a new signal "tls-errors", to be
> emitted as a notification along with a WebKitTLSErrorsInfo object when
> there are TLS errors and the policy is WEBKIT_TLS_ERRORS_POLICY_FAIL
> (no new policy is required).
> 
> The WebKitTLSErrorsInfo object would have this API to find out more
> about the reasons for failure:
> 
> WEBKIT_API GTlsCertificate *
> webkit_tls_errors_info_get_certificate (WebKitTLSErrorsInfo *info);
> 
> WEBKIT_API GTlsCertificateFlags
> webkit_tls_errors_info_get_tls_errors  (WebKitTLSErrorsInfo * info);
> 
> WEBKIT_API const gchar *
> webkit_tls_errors_info_get_host        (WebKitTLSErrorsInfo * info);
> 
> The user agent can allow errors on subsequent loads for this host to be
> ignored through a new public API for WebKitWebContext:
> 
> void
> webkit_web_context_allow_specific_https_certificate_for_host(WebKitWebC
> ontext* context, GtlCertificate* certificate, const char* host).
> 
> Thoughts and feedback?
> 
> Brian
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk