https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/calendar/events
I want to generate link of teams. Can I generate link using token generated by
string[] scopes = new string[] {"https://graph.microsoft.com/.default"};
var result = app.AcquireTokenForClient(scopes);
I have use username password flow but that flow is not recommended as per official documentation
Is there any way to create teams meeting using graph API without usernamepassword flow.
Related
We are trying to implement Azure service bus for managing user "Work Queues"
Background:
We have a web UI pushing new items to a Web API which are persisted to a DB and then pushed to a Service Bus Queue. All messages have a property which denote who can work on the message. For providing a user with the ability to pick messages assigned to them, I am thinking about creating a topic with subscriptions that filter on that property.
Approach
To achieve the above mentioned capability:
I need to register a sender for the queue and a sender for the topic all within the same Web API. I have tried adding the two senders as Singletons but during DI, how do I pick which sender to use ?
services.TryAddSingleton(implementationFactory =>
{
var serviceBusConfiguration = implementationFactory.GetRequiredService<IMessagingServiceConfiguration>();
var serviceBusClient = new ServiceBusClient(serviceBusConfiguration.IntakeQueueSendConnectionString);
var serviceBusSender = serviceBusClient.CreateSender(serviceBusConfiguration.IntakeQueueName);
return serviceBusSender;
});
services.TryAddSingleton(implementationFactory =>
{
var serviceBusConfiguration = implementationFactory.GetRequiredService<IMessagingServiceConfiguration>();
var serviceBusClient = new ServiceBusClient(serviceBusConfiguration.TopicConnectionString);
var topicSender = serviceBusClient.CreateSender(serviceBusConfiguration.TopicName);
return topicSender;
});
I am using the above setup to add the services as singletons and individually I am able to send and receive messages from either the topic or the queue.
How can I register both the implementations and pick which one should be injected when I use DI in the constructor to consume it.
With respect to resolving DI registration for multiple instances of the same type, the first answer to this question illustrates using a service resolver with ASP.NET Core. To my knowledge, that is still the best approach.
For the senders, you could differentiate by checking their EntityPath property to identify whether they point to your queue or topic.
I had created a bot using bot framework composer and integrated it with MS Teams with help of the azure web app.
Now I need to get the login user(MS Team) information i.e. the user who using the bot.
I need to get the user information and log it in the azure application insights using Bot Framework Composer.
Can anyone help me with it?
Get UserID from ${turn.activity.aadObjectId}
Get more user information by Microsoft Graph: https://learn.microsoft.com/en-us/graph/api/user-get?view=graph-rest-1.0&tabs=http
In MS Teams, with each new interaction with the bot, a "conversation Update activity" is first sent to the bot, this is what triggers the welcome greeting. You get back the following context in the returned JSON - in the Turn.Activity memory scope.
...snip...
"serviceUrl":"https://smba.trafficmanager.net/emea/",
"channelId":"msteams",
"from":{
"id":"<<Unique MS Teams Identifier for the end user>>",
"name":"<<AAD firstname surname is returned here>>",
"aadObjectId":"<<GUID is returned here>>",
"role":"user"
},
...snip...
You can Use the aadObjectId to query the MS Graph using an HTTPRequest if you want to get further info. Or just use the persons "name" field (which is from AAD) if that is good enough.
I just started reading/experimenting with the Accounts library yesterday and trying to wrap my head around the participants/signers part in my states.
Let's say I have the following:
1. Mint: A node that issues tokens.
2. Registry: A node that hosts accounts and generates key pairs for them when requested.
3. Wallet: A node that holds tokens on behalf of accounts.
4. I created my own fungible token which basically has an extra field: PublicKey owningAccount
The process:
1. The Registry creates a new account (let's call it Account001), so the Registry is the host of that account.
2. The Mint requests a new key pair for Account001 from Registry
3. The Mint issues a new token to Wallet and sets owningAccount to the key they got for Account001 from Registry, so now Wallet is the holder of the token
So now we have:
1. Registry is the host of Account001
2. Wallet is the holder of the token (on behalf of Account001)
Questions:
1. Is my approach of having those 3 nodes correct? One node controls the supply of tokens, another the users, and last one tracks the "balances" of tokens per user.
2. I want to keep this separation of nodes (assuming it's conceptually correct); and for that reason I don't want to include the owningAccount as part of the participants for the token, so the token will only persist in the vault of Wallet, BUT I will require owningAccount as a signer for various commands (e.g. when moving the token to a new owningAccount; both the holder (i.e. Wallet) and the owner (i.e. Registry on behalf of owningAccount) must sign).
3. In general (let's forget about tokens), if I have a node that manages users and another that manages the state that has owningAccount field, in that state do I need to have owningAccount as a participant? Like I mentioned I'm still trying to figure out the "right" approach (usually things become more clear as I program more), but I would imagine that there should be some decoupling where the owningAccount is just required as a signer for commands related to states that are tied to it, and the participant is mostly just the node to whom that state was issued to.
Roger Willis explained to me on Slack how FungibleToken allows assigning the token to a certain owner (i.e. public key) as opposed to a Party by using the Holder attribute; the process is as follows:
1. The Mint node starts the issue token flow which takes as inputs amount and AccountInfo ref
2. It requests a new public key for the referenced AccountInfo from the Accounts Registry node
3. The received public key is used to get the respective party (i.e. identityService.partyFromKey(receivedPublicKey))
4. The resulting party is assigned as the Holder of the token
5. Remember that a Party is the CordaX500Name (Accounts Registry in our case) and a public key that identifies this entity (in our case it's the public key that mapps to an AccountInfo state (i.e. to a certain user)).
6. So whenever we issue a new token, the holder will always be Accounts Registry party but the same party will have different public keys for different owners/users.
7. With all that being said we no longer need 2 nodes Accounts Registry and Wallets, we will have one node Wallets which holds our AccountInfo states and our tokens where the holder of the tokens is Wallets party but the public key in that party will vary and map to different AccountInfo states depending on who's the owner/user.
I have a problem with ASP.Net Identity used in application scaled to two instances. It seems that we have problem with checking password (checking hashes?) or verifying generated tokens (for example: password reset). When application works on one instance, then everything seems to be fine. It's weird because I read that using ASP.Net Identity in Azure cloud should be safe - it should use the same machine key on both instances.
Our user manager use token provider created below:
public DataProtectorTokenProvider<ExternalUser> Create(string purpose = "GeneralPurpose")
{
var provider = new DpapiDataProtectionProvider(_appName);
var result = new DataProtectorTokenProvider<ExternalUser>(provider.Create(purpose));
return result;
}
What is more, our user manager is singleton, but I think it shouldn't be a difference.
Any idea why it doesn't work on two instances in Azure? I will appreciate any help or advice.
I'm working on a web portal for customers that will connect to Microsoft Dynamics. I don't want to make Dynamics CRM directly a internet facing deployment (IFD), so I'd like to use a separate database that the web interface interacts with and then use web services to move the data between the web portal database and Dynamics CRM.
I'm just looking for thoughts on whether this is the best way to proceed and whether there are any good code examples, etc. that I can look at for implementing this?
I saw Microsoft has a Customer Portal but it looks like it requires (at a cursory glance) an IFD deployment - which I don't want.
First, after creating your ASP.NET project (WebForms or MVC 3), add the following references:
Microsoft.crm.sdk.proxy.
Microsoft.xrm.sdk.
System.Runtime. Serialization.
System.ServiceModel.
In your code-behind Create a class then add the following code:
private IOrganizationService GetCrmService(string userName, string password, string domain, Uri serviceUri)
{
OrganizationServiceProxy _serviceProxy;
ClientCredentials credentials = new ClientCredentials();
credentials.Windows.ClientCredential = new System.Net.NetworkCredential(userName, password, domain);
//credentials.UserName.UserName = userName; // uncomment in case you want to impersonate
//credentials.UserName.Password = password;
ClientCredentials deviceCredentials = new ClientCredentials();
using (_serviceProxy = new OrganizationServiceProxy(serviceUri,
null,
credentials,
deviceCredentials))
{
_serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior());
return (IOrganizationService)_serviceProxy;
}
}
If you want to retrieve multiple records:
string fetch = #"My Fetch goes here";
EntityCollection records = getCrmService().RetrieveMultiple(new FetchExpression(fetch));
I highly recommend to download the SDK or check this
You'll find many samples and walkthroughs which will help you to build good portals.
I think it's a good strategy because:
It allows you to asynchronously put the data entered on the website into the CRM. This decoupling ensures neither the CRM nor the Website will become eachother's bottleneck.
Only the intermediate service layer is internet facing, so you'll be in control over what CRM information would be disclosed/open for alteration if this service layer is compromised.
The architecture you're after is reminiscent of the way the CRM Asynchronous Service works (asynchronous plugins and workflows work this way).:
A job is put in a queue (table) in the CRM DB.
A scheduled service awakes every x seconds and fetches the latest y records from the queue table.
The service performs each job and writes the result (success, error message log) back to the queue table's records.
So the thing that is probably hardest is writing a good scheduled service that never throws an exception (but always digests it) and properly logs the results back to the DB.
To learn more about the Dynamics CRM's "Asynchronous Service Architecture", refer to the following: http://msdn.microsoft.com/en-us/library/gg334554.aspx
It looks like a good approach.
It will improve the performance of both the portal and CRM.
The data shown on portal is NEARLY realtime. i.e it is NOT realtime.
Throughout the development, you better keep checking that there is not TOO MUCH async processing to keep the CRM server busy all time.
I don't think, that the accelerators/portals REQUIRE CRM to be an IFD instance, I guess only the portal part needs to be Internate facing (of course to make it usable for the purpose!)
Anwar is right, SDK is a good lauchpad for such research.
Customer Portal Does not require IFD deployment. And if you do not like the Customer Portal you can always use SDK Extension for Portal development (microsoft.xrm.client.dll & microsoft.xrm.portal.dll and portalbase solution) which are all included in SDK.
There is a great resource regarding how to build portal by using SDK Portal Extenstion.
Dynamics CRM 2011 Portal Development