Brett Styles

My feedback

  1. 129 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    10 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →
    Brett Styles supported this idea  · 
  2. 643 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    86 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →

    Due to various technical limitations, the first iteration of the customer-owned domains functionality will not be available for a few more months. We will provide an update as soon as we can get a more specific ETA.

    If you are looking to use custom domains to use javascript, we are now looking to enable that experience by providing a new (non-customizable) domain. Please look for updates here: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15493536-add-support-for-javascript-inside-the-custom-ui-br

    /Parakh

    Brett Styles supported this idea  · 
  3. 59 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Web Apps » API Apps  ·  Flag idea as inappropriate…  ·  Admin →

    Hello!

    At the moment our recommended method for checking the identity of the current user is to check several attributes added to incoming requests. This is to allow your application to go completely in and out of memory on lower priced tiers without “always-on.” Check out the tutorial below for the header names.
    https://docs.microsoft.com/en-us/azure/app-service-api/app-service-api-authentication

    We would like to have language specific auth functionality like this in the future. I am placing this item in “unplanned” to be used in future planning sessions.

    thanks for your feedback!
    Alex
    Azure App Service Team

    Brett Styles commented  · 

    It really limits the usefulness of the API if a REST endpoint gives all users the same access rights and scope. The scenario where it returns data specific to the logged in user or group (user v admin etc) currently means two API apps one Admin and one user exposing the same REST endpoint.

    The gateway already intercepts the request to validate the token when accessing the endpoint so handing that token on to the WebApi to run an OAuth2 authorize cycle to the gateway would at least give us a way to access the claims principal.

    Brett Styles supported this idea  · 

Feedback and Knowledge Base