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-boun...@lists.webkit.org [mailto:webkit-gtk-
> boun...@lists.webkit.org] On Behalf Of Brian Holt
> Sent: 04 October 2013 16:03
> To: webkit-gtk@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
