<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 02/18/2016 02:00 PM, Morgan Fainberg
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAGnj6as5TSgfos-XHaUC=P89NzHvGPxVdP8D6hzP06gWkvSokA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>Adam,<br>
            <br>
          </div>
          CORS shouldn't need catalog integration ever. CORS is a layer
          above anything in the service catalog and doesn't provide
          extra security except signalling to the javascript vm it can
          access resources outside of it's current domain; something
          that can be worked around in many ways including using a
          non-javascript http client. The underlying application can
          still reject the request.<br>
        </div>
      </div>
    </blockquote>
    OK, so Catalog is a vestige of the old discussion.  Look instead at
    what we do with Federations Trusted Dashboard.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n532">http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n532</a><br>
    <br>
    That is really what I was getting at:<br>
    <br>
    Its not a question of the remote application rejecting the token. 
    It is Keystone refusing to tell the browser that the remote
    application is allowed to read the token.<br>
    <br>
    If the deployer does and all-in-one, and all services are on port
    443, CORS is not an issue.<br>
    <br>
    If Each Service has its own port or hostname, then each service
    needs to know the list of approved dashboards.  Since we do this in
    Keystone already, recommend we have the CORS middleware use the same
    property.<br>
    <br>
    CONF.federation.trusted_dashboard<br>
    <br>
    <br>
    <blockquote
cite="mid:CAGnj6as5TSgfos-XHaUC=P89NzHvGPxVdP8D6hzP06gWkvSokA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>I don't see service catalog integration as a blocker for
          CORS.<br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Thu, Feb 18, 2016 at 10:29 AM, John
          Garbutt <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="HOEnZb">
              <div class="h5">On 18 February 2016 at 17:58, Sean Dague
                <<a moz-do-not-send="true"
                  href="mailto:sean@dague.net">sean@dague.net</a>>
                wrote:<br>
                > On 02/18/2016 12:17 PM, Michael Krotscheck wrote:<br>
                >> Clarifying:<br>
                >><br>
                >> On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <<a
                  moz-do-not-send="true" href="mailto:sean@dague.net"><a class="moz-txt-link-abbreviated" href="mailto:sean@dague.net">sean@dague.net</a></a><br>
                >> <mailto:<a moz-do-not-send="true"
                  href="mailto:sean@dague.net">sean@dague.net</a>>>
                wrote:<br>
                >><br>
                >>     Ok, to make sure we all ended up on the
                same page at the end of this<br>
                >>     discussion, this is what I think I heard.<br>
                >><br>
                >>     1) oslo.config is about to release with a
                feature that will make adding<br>
                >>     config to paste.ini not needed (i.e.<br>
                >>     <a moz-do-not-send="true"
                  href="https://review.openstack.org/#/c/265415/"
                  rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265415/</a>
                is no longer needed).<br>
                >><br>
                >><br>
                >> I will need help to do this. More below.<br>
                >><br>
                >><br>
                >>     2) ideally the cors middleware will have
                sane defaults for that set of<br>
                >>     headers in oslo.config.<br>
                >><br>
                >><br>
                >> I'd like to make sure we agree on what "Sane
                defaults" means here. By<br>
                >> design, the CORS middleware is generic, and
                only explicitly includes the<br>
                >> headers prescribed in the w3c spec.  It should
                not include any<br>
                >> additional headers, for reasons of downstream
                non-openstack consumers.<br>
                >><br>
                >><br>
                >>     3) projects should be able to apply new
                defaults for these options in<br>
                >>     their codebase through a default override
                process (that is now nicely<br>
                >>     documented somewhere... url?)<br>
                >><br>
                >><br>
                >> New sample defaults for the generated
                configuration files, they should<br>
                >> not live anywhere else. The CORS middleware
                should, if we go this path,<br>
                >> be little more than a true-to-spec
                implementation, with config files<br>
                >> that extend it for the appropriate API.<br>
                >><br>
                >> The big question I now have is: What do we do
                with respect to the mitaka<br>
                >> freeze?<br>
                >><br>
                >> Option 1: Implement as is, keep things
                consistent, fix them in Newton.<br>
                ><br>
                > The problem with Option 1 is that it's not fixable
                in Newton. It<br>
                > requires fixing for the next 3 releases as you have
                to deprecate out<br>
                > bits in paste.ini, make middleware warn for removal
                first soft, then<br>
                > hard, explain the config migration. Once this lands
                in the wild the<br>
                > unwind is very long and involved.<br>
                ><br>
                > Which is why I -1ed the patch. Because the fix in
                newton isn't a revert.<br>
                <br>
              </div>
            </div>
            +1 on the upgrade impact being a blocker.<br>
            Certainly for all folks meeting these:<br>
            <a moz-do-not-send="true"
href="https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements"
              rel="noreferrer" target="_blank">https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements</a><br>
            <br>
            This will require lots of folks to pitch in a help, and bend
            the<br>
            process a touch.<br>
            But that seems way more reasonable than dragging our users
            through<br>
            that headache.<br>
            <br>
            Thanks,<br>
            John<br>
            <div class="HOEnZb">
              <div class="h5"><br>
__________________________________________________________________________<br>
                OpenStack Development Mailing List (not for usage
                questions)<br>
                Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                  rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>