Adam Weigert

My feedback

  1. 2 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Storage » General  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert shared this idea  · 
  2. 4 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  2 comments  ·  API Management » API management experience  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  3. 10 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  API Management » Developer portal  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  4. 7 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  API Management » Policies  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert shared this idea  · 
  5. 6 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Azure Active Directory » Other  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert shared this idea  · 
  6. 44 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Azure Container Registry  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  7. 12 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Azure Container Registry  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  8. 8 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Azure Container Registry  ·  Flag idea as inappropriate…  ·  Admin →

    Based on all the great feedback, we’re adding token based authentication to the repo-based permissions capability. Customers can configure time based tokens, for access to specific repos, with RBAC.
    We don’t have an ETA yet, but we expect to be in preview by this summer.

    Adam Weigert supported this idea  · 
  9. 82 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Azure Container Registry  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  10. 64 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  (General Feedback) » Offers  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  11. 147 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  12. 299 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Just to provide an update, we are close to launching a private preview. We are in the final testing stages for this feature. We will have another update in the next few weeks with instructions on how to join the private preview.

    Adam Weigert supported this idea  · 
  13. 178 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Thank you. We will examine the experience of duplicate sign ups across Identity providers. Would performing this check by using the email address be sufficient?

    BTW, Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview…

    We look forward to your feedback

    /Jose Rojas

    Adam Weigert supported this idea  · 
  14. 494 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    53 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

    Adam Weigert supported this idea  · 
  15. 274 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    36 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  16. 749 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    103 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
  17. 1 vote
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  API Management » Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert commented  · 

    If custom sections could be added based on a critiera (group membership or product of subscription) then the following could be helpful to the developer.

    The primary use case I have would be around stating the rate limit thresholds for either a particular product or group of users, e.g. Production has X rate limit, Staging has Y rate limit, or group A has X rate limit, group B has Y rate limit.

    This capability would keep more documentation about the API and its uses in the APIM portal and accessible to the developer instead as tribal knowledge and prevent it from being global knowledge.

    As a secondary note, I'm not sure this capability exists today, but the ability to use Properties within the docs would be nice as the rate limit is most likely a Property and could be imported into the docs so that when the Property value is updated then the docs would also be updated. Maybe not with replacement but with custom markdown support for pulling the property value

    Adam Weigert shared this idea  · 
  18. 10 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  API Management » API management experience  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert commented  · 

    I'd also agree, if we could deploy an Azure Public IP as a reservation and then bind the service to that then we'd have further assurance that just redeploying or changing the networking wouldn't change the public IP.

    I think this is less of an issue for internal vnets as I typically scope the entire subnet range for network ACLs.

  19. 48 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  4 comments  ·  API Management » Lifecycle  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert supported this idea  · 
    Adam Weigert commented  · 

    Yes. We are moving from an APIM instance per environment to a developer instance and a production instance. We are using products to manage the environment relationship and policies in the product scope to change the backend systems. This is fairly cumbersome with multiple products, e.g. consumers and then needing 1 to N versions of that product, one for each environment.

    The con of this approach is that we don't really have a good test bed for trying changes outside of the developers unless we let the other developer teams use the developer instance, which is not what we want as it impacts their stability during their development efforts.

    What this model does help us do is be much better about the changes since the changes could impact production. Things like understanding the impact on changes to APIs and the need for versioning as well as better test plans for the dev instance are necessary for success instead of nice to haves.

    Adam Weigert shared this idea  · 
  20. 293 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  12 comments  ·  API Management » Developer portal  ·  Flag idea as inappropriate…  ·  Admin →
    Adam Weigert commented  · 

    Having the ability to scope an operation to a group would be helpful. Use case would be a Support API that has commands that Level1 support teams can use and Level2 support teams can use other operations but they are all the same API. Today I would have to have a Level1 Support API and a Level2 Support API and use products to control which one sees which API.

    This feature would let me have one Support API and visibility to the operation would be managed based on the group, defaulting to "Developers" of course. This could also be handy in providing "Developer" API operations and "Guests" API operations, e.g. a heartbeat / service status API could be available to "Guests" so anyone good see that visibility, but deeper interaction on the monitoring API could be provided to those with the Developers group.

← Previous 1

Feedback and Knowledge Base