1. 17 Feb, 2016 3 commits
  2. 15 Feb, 2016 10 commits
    • Robert Knight's avatar
      Make annotation directive more consistent with other directives · 151335a1
      Robert Knight authored
       * Make it an element directive and use the existing utility
         functions for instantiating them in tests
       * Use '=' bindings for input properties and 'on<EventName>' names
         for events
       * Remove unused 'showReplyCount' input property and the
         shouldShowNumReplies() function which was only used
         as the argument to this property.
      151335a1
    • Sean Hammond's avatar
      Merge pull request #2954 from hypothesis/better-handling-of-missing-blacklist · e00042e4
      Sean Hammond authored
      Don't crash out if username blacklist doesn't load
      e00042e4
    • Nick Stenning's avatar
      Merge pull request #2961 from hypothesis/frontend-cleanups · c11d040c
      Nick Stenning authored
      Frontend cleanups
      c11d040c
    • Sean Hammond's avatar
      Merge pull request #2957 from hypothesis/fix-reply-notification-worker · 66dd9d02
      Sean Hammond authored
      Fix reply notification worker
      66dd9d02
    • Robert Knight's avatar
      Fix missing var declarations · b1817f15
      Robert Knight authored
      These files were converted from CoffeeScript and 'use strict'
      was never added.
      b1817f15
    • Robert Knight's avatar
      Remove compass mixins for transition properties · edc2681a
      Robert Knight authored
      This removes the use of compass mixins for transition
      properties, where the mixin was used for vendor prefixing,
      a problem now solved by autoprefixer.
      edc2681a
    • Robert Knight's avatar
      Make app directives compatible with jQLite · b5d4e7ba
      Robert Knight authored
      This enables the sidebar app to function with only
      jQLite, rather than the full jQuery library.
      
      The main differences are:
      
       - jqLite's find() method only supports tag names.
         Element.querySelector() can be used instead
       - jqLite-wrapped input elements do not have a focus()
         method. Just call focus() on the input instead
       - The DOM focus() and select() methods are not fluent
         like their jQuery counterparts
      b5d4e7ba
    • Robert Knight's avatar
      Add missing compass import in spinner.scss · 1d228e33
      Robert Knight authored
      1d228e33
    • Nick Stenning's avatar
      Merge pull request #2948 from hypothesis/BPA1eZ9O-add-developer-api-tokens · 467b740d
      Nick Stenning authored
      Add developer API tokens
      467b740d
    • Sean Hammond's avatar
      Add simple, long-lived API tokens · 5a319491
      Sean Hammond authored
      Add a /profile/developer/ page where users can generate and re-generate
      their API token. This token can be used as a Bearer token in the
      Authorization header in API requests instead of using one of the more
      complex and short-lived JWT tokens that the client uses to authenticate
      API requests.
      
      The tokens are just randomly generated opaque strings, each one
      associated with one user account. There's 0 or 1 token per user, and the
      user can regenerate their token at any time. The tokens are stored in a
      `token` table in the db that just maps token values to userids.
      
      Notes:
      
      - Our authentication policy now calls the new API token validator first
        for API requests. If this validator does not accept the token, then it
        passes it to the legacy JWT validator (which is still used by our
        client).
      
        The idea is that if we add more types of API token in the future, the
        authentication policy will have a list of different validator
        functions for different token types, and will try each validator in
        turn until either one of them accepts the token or it runs out of
        validators.
      
        The use of a type prefix string at the beginning of tokens means that
        validators can usually reject tokens without a db lookup, so we won't
        end up with one db lookup per validator.
      
      - The new tokens always start with u"6879-". If a token sent by a user
        doesn't start with this prefix then the token validator can reject it
        out of hand, without doing a database lookup.
      
        An opaque number is used for this prefix because we want users to
        treat API tokens as opaque, rather than using a human-readable prefix
        that makes it obvious what type of token you're looking at. (But the type
        of the token is not "secret" in any real sense.)
      
        In the future it's intended that we'll have different types of tokens
        identified by different prefixes, and different types of token might
        (for example) give access to different capabilities.
      
      - The legacy JWT tokens (still used by our own client) do not have any
        such prefix. If all other token validators (currently just the one new
        API tokens validator) reject a token, then the auth policy will fall
        back to the legacy JWT token validator.
      
        I think it might be possible that a JWT by random chance could begin
        with u"6879-". If that happens then the new API tokens validator would
        not reject the token based on its prefix and would do a db lookup, but
        the lookup would return nothing and the validator would then reject
        the token, and the auth policy would then move on to the legacy JWT
        validator which would accept the token. So it would be okay.
      
      - There's no foreign key constraint from the token table's userid column
        to the user table, because the user table belongs to the app whereas
        the token table belongs to the api.
      5a319491
  3. 12 Feb, 2016 10 commits
  4. 11 Feb, 2016 6 commits
  5. 10 Feb, 2016 1 commit
    • Robert Knight's avatar
      Improve capture of sidebar injection errors · 3a01aa8b
      Robert Knight authored
       * Capture the tab URL as context when injecting the sidebar
         fails, for use in debugging.
      
       * Switch tests to use the toResult() helper instead of
         Promise.catch() to handle assert errors inside
         catch blocks properly.
      
       * Handle the Error-like objects used by chrome.extension.lastError
         better.
      
         When a Chrome async API fails, it sets chrome.extension.lastError
         to an Error-like object with a 'message' property. Since this
         object is not an instance of Error, RavenJS stringified it
         with .toString(), resulting in an unhelpful '[object Object]'
         message in Sentry.
      
         This commit adds logic to extract out the message property
         of such objects when capturing exceptions.
      3a01aa8b
  6. 09 Feb, 2016 5 commits
  7. 08 Feb, 2016 3 commits
  8. 05 Feb, 2016 2 commits