Skip to content
Snippets Groups Projects
  1. Sep 01, 2024
  2. Aug 31, 2024
  3. Aug 30, 2024
  4. Aug 26, 2024
  5. Aug 25, 2024
  6. Aug 23, 2024
    • Adam Williamson's avatar
      Make logged_in more accurate · e7c51daa
      Adam Williamson authored
      
      I found this while writing integration tests. If you try to login
      with an incorrect username and password, mwclient correctly raises
      mwclient.errors.LoginError...but if you then check logged_in, it
      is True. Clearly that's wrong.
      
      The logic for setting logged_in will basically consider us logged
      in any time we process an API call and there is no 'anon' key in
      the userinfo dict *or there is no userinfo dict at all*. The last
      API call processed on a failed login attempt has no userinfo
      dict.
      
      This tweaks it so we only changed the logged_in value (in either
      direction) if the API call we're handling has a userinfo dict.
      
      We also fix the type of the empty userinfo we create if there
      isn't one in the call (no idea why it was a tuple, it doesn't
      really matter but it's weird) and explicitly set self.logged_in
      to False in Site initialization. I don't think this is strictly
      necessary as we can expect the init process to result in at least
      one API call with a userinfo dict, but it feels more correct.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      e7c51daa
  7. Aug 22, 2024
    • Marc Troelitzsch's avatar
      refactor: simplify clientlogin logic · 3c7244ed
      Marc Troelitzsch authored
      - Removed the unnecessary try/catch block around the get_token call. The
        code would already have thrown an exception earlier if the site was
        uninitialized, making this block redundant.
      - Eliminated the while True loop, as every branch of the loop had a
        return statement, preventing it from executing more than once.
      - Replaced outdated printf-style string formatting with str.format().
      - Renamed the `login` variable to `response`
      3c7244ed
    • Marc Troelitzsch's avatar
      fix: Automatically initialize `Site` after successful `clientlogin` · 78006fc7
      Marc Troelitzsch authored
      This fix ensures that the `Site` object is properly initialized after a
      successful `Site.clientlogin`, matching the existing behavior of
      `Site.login()`.
      
      Previously, developers needed to manually invoke `Site.site_init()`
      after using `clientlogin`, which could lead to unexpected issues,
      especially during migration from `login` to `clientlogin`.
      
      For example, the following code works with `Site.login`:
      
      ```python
      site = mwclient.Site('localhost:8080', path='/', scheme='http')
      site.login('username', 'super-secret')
      with open('/tmp/image.png', 'rb') as f:
          site.upload(f, 'image.png', 'Some test upload', ignore=True)
      ```
      
      But when using `Site.clientlogin` without this fix, the code would fail
      with `mwclient.errors.InsufficientPermission: image.png`:
      
      ```python
      site = mwclient.Site('localhost:8080', path='/', scheme='http')
      site.clientlogin(username='username', password='super-secret')
      with open('/tmp/image.png', 'rb') as f:
          site.upload(f, 'image.png', 'Some test upload', ignore=True)
      ```
      78006fc7
  8. Aug 21, 2024
  9. Aug 11, 2024
    • Adam Williamson's avatar
      Bump version: 0.10.1 → 0.11.0 · da48d446
      Adam Williamson authored
      da48d446
    • Adam Williamson's avatar
    • Adam Williamson's avatar
      a1895931
    • Adam Williamson's avatar
      Deprecate `limit` for `api_chunk_size`, extend `max_items` (#259) · 95c0b0fc
      Adam Williamson authored
      
      As discussed in #259, the `limit` parameter - to the low-level
      `listing.List` and its subclasses, and to various higher-level
      functions which ultimately return `List` or `GeneratorList`
      instances - is confusing and misleading.
      
      It is passed through to the API calls, and effectively specifies
      how many items a single API call will return. But because our
      `List` yields a single item at a time and will keep doing API
      calls until the API says there's no more data, it does not limit
      how many items our `List` will yield, nor specify its chunk size.
      It seems natural to expect that `List(limit=10)` or
      `page.revisions(limit=10)` will give you a generator that yields
      only 10 items, or yields 10 items at a time, but it does not; it
      gives you a generator which queries the API in chunks of 10 items
      at a time, but will yield every item the API gives it, one by one.
      
      This is probably not ever how we really intended mwclient to work
      (there's an old `# NOTE: Fix limit` comment which implies as much)
      but it has worked this way for 16 years, so we should probably
      not change it just in case someone really has a need to specify
      the API chunk size for some reason, or some code somehow happens
      to implicitly rely on it behaving the way it does.
      
      So, this keeps the behaviour of the `limit` param wherever it
      exists, but triggers a deprecation warning. Everything that had
      a `limit` param now also has an `api_chunk_size` param that does
      the same thing, but is more explicitly named and does not trigger
      a deprecation warning. And everything that had a `limit` param
      now also has a `max_items` param that does what it sounds like,
      and what people are more likely to want - sets an absolute limit
      on the number of items the generator will yield.
      
      For efficiency, if `max_items` is set, neither `limit` nor
      `api_chunk_size` is set, and `max_items` is below
      `site.api_limit`, we set the API chunk size to `max_items` so
      we only retrieve as many items as we actually need.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      95c0b0fc
  10. Aug 08, 2024
  11. Jul 17, 2024
  12. Jul 16, 2024
  13. Jul 11, 2024
  14. Jun 01, 2024
  15. May 18, 2024
  16. May 06, 2024
Loading