1. 24 Jan, 2018 1 commit
  2. 23 Jan, 2018 1 commit
  3. 10 Jan, 2018 5 commits
  4. 09 Jan, 2018 1 commit
  5. 04 Jan, 2018 1 commit
  6. 11 Dec, 2017 1 commit
  7. 30 Nov, 2017 1 commit
  8. 16 Nov, 2017 1 commit
  9. 14 Nov, 2017 1 commit
  10. 30 Oct, 2017 1 commit
  11. 19 Oct, 2017 1 commit
  12. 18 Oct, 2017 1 commit
  13. 13 Oct, 2017 1 commit
  14. 03 Oct, 2017 1 commit
  15. 02 Oct, 2017 1 commit
  16. 27 Sep, 2017 1 commit
  17. 10 Aug, 2017 1 commit
  18. 07 Aug, 2017 6 commits
  19. 17 Jul, 2017 1 commit
  20. 03 Jul, 2017 1 commit
  21. 22 Jun, 2017 3 commits
    • Tomas Popela's avatar
      Authentication should success in some cases when gss_init_sec_context() returns error · aefe8eac
      Tomas Popela authored
      Unfortunately, so many programs (curl, Firefox) ignore the return token that is
      included in the response, so it is possible that there are servers that send
      back broken stuff.  Try to behave in the right way (pass the token to
      gss_init_sec_context()), show a warning, but don't fail if the server returned
      There is an internal Red Hat site that triggers the described situation
      and the "Invalid token was supplied: Unknown error" is being printed to
      the console.
    • Tomas Popela's avatar
      Can't access sites that request closing the connection during 401 · 1d532c8e
      Tomas Popela authored
      When a 401 message is received, a new token is generated and saved in
      the SoupNegotiateConnectionState's respose header. Later when the connection is
      closed (as requested by the server), the state is destroyed together with
      the response header. When a new request is being created and we are asked for
      the connection authorization, the newly created connection state doesn't have it
      set. At this point if the connection state is newly created, generate a new token
      together with the response header that will be returned as the connection
      Also modify how the warning from the soup_gss_build_response is printed
      to differentiate if there was a failure during soup_gss_client_init or
    • Tomas Popela's avatar
      Rework some of the SoupAuthNegotiate internals · 05a88c3a
      Tomas Popela authored
      There are several problems with the current state. The main problem is
      that the SoupMessage can outlive the SoupAuthNegotiate object and if the
      SoupMessage signals handlers are active then they could be called with invalid
      SoupAuthNegotiate object. To avoid that use the g_signal_connect_data() and
      increase the reference on the SoupAuthNegotiate object. Also rework how
      we are connecting the 'got_headers' signal handler to the SoupMessage object, so
      they are really connected only once, even if the GSS mechanism involves
      multiple rounds.
      The whole concept of how we are working with the
      SoupAuthNegotiateConnectionState is also wrong. When the connection state is
      created it's saved to the private structure and then accessed from
      there. The problem is that another state for different message could be
      created in the mean time and that one would overwrite the currently set (or if
      one would be freed then it would erase the one that is currently set). To solve
      this expose the SoupConnectionAuth's get_connection_state_for_message() and
      call it when we need the connection state object.
  22. 03 May, 2017 1 commit
    • Carlos Garcia Campos's avatar
      Async request never completes if message is cancelled before reading body data while being paused · 9f7ab7bc
      Carlos Garcia Campos authored
      The async ready cabllack is never called in this case. I noticed this in WebKit, it happens if you
      open a website that is HTTP authenticated and close the tab without responding to the auth dialog.
      What happens internally is that we pause the message on authenticate signal, and then we cancel the
      message. The message and its io are properly finished, but the request async ready callback is never
      called, which caused the WebKit object to be leaked, because it takes a reference of the object on
      send_sync and releases on the async ready callback.
      The sequence of libsoup internals is the following one:
       1- Message starts normally and on ready async_send_request_running is called that sets io_started = TRUE
          and starts the io
       2- Before message io started to read the body data, it can be authenticate or got-headers, for example,
          the message is paused.
       3- Next call to try_run_until_read calls soup_message_io_run_until_read() that returns G_IO_ERROR_WOULD_BLOCK
          because the message is paused.
       4- Because of the G_IO_ERROR_WOULD_BLOCK try_run_until_read creates a SoupMessageSource. Since the message is
          paused but there's io in progress, the SoupMessageSource is created witout a bae source, and therefore it's
          not cancellable with the passed GCancellable.
       5- The message is cancelled, soup_session_cancel_message checks that the message is paused, so it marks the
          item as not paused, and also unpause the message io, sets the status message, cancels the cancellable and
          kicks the item queue.
       6- When the item is processed again the status is changed to FINISHING and then soup_message_finished is called.
       7- async_send_request_finished() is called due to message finished signal emission, but returns early without
          calling async_send_request_return_result because item->io_started is TRUE (see step 1).
       8- The SoupMessageSource is still alive, but since it's paused and now message doesn't have io because it was
          finished, the source is never dispatched (message_source_check always returns false because paused is TRUE
          and io is NULL).
      The problem is in this last step, I think the source should be dispatched when the io becomes NULL and the
      source was created paused.
  23. 30 Apr, 2017 1 commit
  24. 25 Apr, 2017 1 commit
  25. 23 Feb, 2017 1 commit
    • Chun-wei Fan's avatar
      Visual Studio builds: Move projects to win32/ · 94b6b3da
      Chun-wei Fan authored
      This enables one to go down one less level into the tree to access the Visual
      Studio build files, and was belated as this was suggested by Dan as we move
      the projects in the GLib/GTK+ stack into win32/ from build/win32/.
      This also enables syncing the Makefile-newvs.am, Makefile.msvcproj and
      Makefile.msvc-introspection autotools modules, as well as the common NMake
      Makefile bits from GLib and G-I masters, so that we are more consistent
      accross the board.
  26. 22 Feb, 2017 3 commits
    • Carlos Garcia Campos's avatar
      Abort session after a new proxy resolver is set · 28849060
      Carlos Garcia Campos authored
      It's currently don only when proxy-uri property is set, but it should
      always be done after a new proxy resolver is set.
    • Carlos Garcia Campos's avatar
      auth: do not use cached credentials in lookup method when flag... · 5efaac68
      Carlos Garcia Campos authored
      auth: do not use cached credentials in lookup method when flag SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE is present
      This is causing that a request with flag
      SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE success if a previous request without
      the flag stored the credentials. This patch also fixes another issues
      with the test /auth/message-do-not-use-auth-cache, the case of providing
      the credentials in the url was working because do_digest_nonce_test()
      didn't disconnect the authenticate signal that was actually used. This
      is because soup_uri_to_string removes the password from the uri. The
      test needs to use a custom message created with
      soup_message_new_from_uri() instead of using do_digest_nonce_test().
    • Carlos Garcia Campos's avatar
      auth: Fix async authentication when flag SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE is used · 25f77b51
      Carlos Garcia Campos authored
      When the flag SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE is used, it's not possible
      to successfully authenticate, and SOUP_STATUS_UNAUTHORIZED is always
      returned even when soup_auth_autenticate was called with the right
      credentials. This happens because we set the auth on the soup message right
      after emitting the authenticate signal only if it was authenticated. If the
      signal pauses the message, the auth will no longer be associated to the message,
      and not cached either because flag SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE is
      present. Since we always check if the auth returned by
      soup_auth_get_message is ready before trying to use it, we can simply
      always set the auth on the mssage right after emitting the authenticate
      signal even if it was not authenticated yet. If it's eventually
      authenticated then got-body callback will check it's ready to re-queue
      the message as expected.
  27. 12 Dec, 2016 1 commit