Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Commits on Jan 14, 2014
Commits on Dec 3, 2013
Commits on May 17, 2013
  1. Change expected values based on a discussion with @jrgm

    authored
    While the original expected values were more correct in the
    majority of these tests, we shouldn't impose too much logic on the
    nginx rules that will be making the tests pass.
    
    It's better to have slightly less precise HTTP error codes but to
    have an easier (and more maintainable) nginx config.
  2. Add test requested by Gene on mozilla/identity-ops#36

    authored
    This never worked on production, so it should continue to fail.
  3. Allow 404 here even though a 405 would be better

    authored
    As agreed on mozilla/identity-ops#31 this
    should be fixed in code, not in nginx.
  4. Change the name of the first background image

    authored
    Which image we pick doesn't matter, but our logic only looks for
    the first one, it doesn't loop through all possible matches.
Commits on Apr 19, 2013
  1. @gene1wood

    adding in checks for browserid post functionality

    gene1wood authored committed
Commits on Apr 17, 2013
  1. Fixes for requests 1.0

    authored
Commits on Feb 26, 2013
  1. Fix top level redirects for verifier.login.persona.org

    authored
    The top-level (GET /) of each domain should redirect to the main
    Persona website (currently https://login.persona.org).
Commits on Feb 19, 2013
Commits on Oct 31, 2012
Commits on Sep 26, 2012
  1. Tighten up the serving of include.js

    authored
    This tests GH-2419 and GH-2420.
Commits on Sep 14, 2012
Commits on Sep 4, 2012
  1. https://www.browserid.org/verify should continue to work

    authored
    The old verifier has always worked on https://www.browserid.org/verify
    and I don't see any reason to break this.
  2. Adding a genuine 405 for the verifier

    authored
    In this case, the URL is the right one (including the scheme) and
    the only thing that needs to be fixed is the method.
    
    Note that for this one, the spec says that we need to include an
    "Allow" header:
    
      http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7
  3. Replace most 405s with 404s

    authored
    As far as I can tell, 405 is only used for method mismatch (e.g.
    POST v. GET):
    
      http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6
    
    In these cases, parts of the URL are wrong so 404 seems like a
    better fit.
Commits on Aug 23, 2012
  1. Changing http and https calls to www.anosrep.org/foo to 404s

    Eugene Wood authored
    benadida writes here : https://bugzilla.mozilla.org/show_bug.cgi?id=781838#c15
    
    > 1. a request for "http://www.anosrep.org/" would redirect to
    > "http://anosrep.org/" which wound then do a second redirect to
    > "https://login.anosrep.org/"
    
    Yes, I'm okay with this 2-step redirect because in case anyone caches the www --> non-www redirect (the first one), and we start serving diff stuff at anosrep.org, then I'd like that to work.
    
    > 2. a request for "https://www.anosrep.org/" would redirect to
    > "https://anosrep.org/" which wound then do a second redirect to
    > "https://login.anosrep.org/"
    
    Same reasoning. There's a chance we serve something different at anosrep.org in the future, don't want to write rules that imply that login.* and anosrep.org are the same site.
    
    > 3. a request for "http://www.anosrep.org/about" would return a 404
    > 4. a request for "https://www.anosrep.org/about" would return a 404
    
    Yes, I'd like that. I would rather be stricter about the API we expose and then loosen it if needed.
  2. Changing expected 405s for http posts to the verifier to 404s

    Eugene Wood authored
    benadida writes here : https://bugzilla.mozilla.org/show_bug.cgi?id=781838#c15
    
    > You'd said "POST http://verifier.login.anosrep.org/verify 400
    >
    > --> yes."
    >
    > Do you really want to serve back a 400 Bad Request on an http POST to
    > "http://verifier.login.anosrep.org/verify" or would you like to serve a 405
    > Method Not Allowed like we do for other POSTs to http?
    
    Let me tweak the request based on a conversation with Francois. For all plain HTTP requests to the verifier, we should give a 404 with an error message that says "the verifier is only available over SSL."
  3. Changing expected static http responses

    Eugene Wood authored
    benadida writes here : https://bugzilla.mozilla.org/show_bug.cgi?id=781838#c15
    
    (In reply to Eugene Wood [:gene] from comment #13)
    >
    > You'd said "GET http://static.login.anosrep.org/ https://login.anosrep.org/
    >
    > --> for top-level path only."
    >
    > Does this mean you really want to allow serving of static resources over
    > http? For example, you want to serve back a 200 when a request for
    > http://login.anosrep.org/v/fb5534092a/production/browserid.css ?
    
    Ahah, good catch. So for I would suggest that
    
    - top-level static path on HTTP redirect to top-level login.* path on HTTPS.
    - every other URL on plain HTTP static should give a 404.
    
    so that we only serve static content from https.
  4. jrgm mentioned "One major mistake in the current rules, is that 'POST

    Eugene Wood authored
    https://browserid.org/verify'; is 405. That URL must never be blocked as
    it is
    the URL that >90% of the current Relying Parties use."
    
    So I'm fixing that in the test case list
  5. @jrgm
  6. @jrgm
  7. @jrgm
Commits on Aug 22, 2012
  1. @jrgm

    remove default readme

    jrgm authored
Something went wrong with that request. Please try again.