Hopefully a simple question. In the Exchange Powershell API, there are functions such as "get-casmailbox" to set a mailbox to be accessible via OWA, etc. I am trying to integrate this type of functionality in to a C# program, and it is absurd to call Powershell in C# just to interact with Exchange.
I have successfully added the EWS API, but cannot find such functionality like get-casmailbox.
Is there an alternative, or am I stuck with doing get-casmailbox and set-casmailbox in Powershell only?
I think it is absolutely okay to use Powershell as it is the only interface to administer Exchange Settings in a reliable way.
You could look at the protocolSettings Attribute of the user - these settings are stored there. But I absolutely do not recommend to change them directly. (Although it might work)
Enjoy -tom
Related
I am working on an application which requires a feature to allow user to send emails . I looked for SMTP but it requires password ( and i guess it should be used for organization level emails with one time configuration) . I also looked for MAPi using this repo but i could not make it work
https://github.com/PandaWood/Simple-MAPI.NET
So is there a way to achieve this , specifically opening default mail application of the user with attachment.
Thanks
Here is what MS states for the Simple MAPI:
The use of Simple MAPI is discouraged. It may be altered or unavailable in subsequent versions of Windows.
Simple MAPI is a set of functions and related data structures you can use to add messaging functionality to Windows-based applications written in C, C++, or Visual Basic. You can use pinvoke to call Simple MAPI functions from your application, see Writing cross platform P/Invoke code for more information.
Also you may consider using the mailto protocol or just automating Outlook (if it is installed on the system). That's the most easiest way.
If you deal with Exchange profiles you may also consider using EWS or Graph API. Read more about EWS in the Explore the EWS Managed API, EWS, and web services in Exchange article.
I'm trying to figure out how to access MS Teams or Skype commands, which are listed here, Teams commands link from within c#. Is there any way this can be done?
I can execute the commands from powershell, by importing the teams or skype module, but I want to execute the commands from within c# instead and retrieve the result data in order to process it afterwards. Is there any documentation on the subject? Or maybe somebody has done this.
EDIT: For example, this is how I would run the command "Get-CsOnlineVoiceRoute" in powershell. Its a pseudocode
Import-Module SkypeOnlineConnector
$sfbSession = New-CsOnlineSession -SessionOption (some options)
Import-PSSession #sfbSession -AllowClobber
Get-CsOnlineVoiceRoute
In the answers bellow, the guys suggest that I can use the Microsoft Graph API to do this. But can somebody show me an example call. Maybe with the command im using. How can I get the same results using the API? Or is there any documentation about what ps command relates to what api calls?
What you are looking for is to use the Microsoft Graph API. The Microsoft Graph API is a RESTful API that enables you to access Microsoft Cloud service resources (e.g. even Teams). The MicrosoftTeamsPowerShell PowerShell module is simply a convenient wrapper making API calls on your behalf for you. Since C# can also make RESTful API calls, I recommend accessing the API directly for the most seamless user experience.
Accessing and configuring Microsoft Graph API is beyond the scope of SO, and I recommend going over their Graph Quick Start page to go over some basic code samples to get you started. If you can do this type of request:
{HTTP method} https://graph.microsoft.com/{version}/{resource}?{query-parameters}
Then you are all set up to access the API. The specific API section/resource you are interested in is the Microsoft Graph Teams API. The Microsoft documentation has more info on what you might be trying to achieve.
Other things to keep in mind is, if you can't seem to do something, that while v1.0 of the API is "Production" live, the beta version has many more additional resources available and may have a feature you need. (esp. when dealing with Azure Active Directory, there are certain things that can only be done with the beta version of the API). I find the Graph Explorer to be extremely helpful in finding out exactly what type of requests I need to make before I start coding.
You can use the Graph API call to call teams commands. Could you please check this sample?
I want to create a game within the Unity game engine in C# with .NET where I can securely connect out to a private server, and read and write data from/to the server. I understand how to do this in a non-secure way, where I would setup a private SQL database with a webpage interface between the two.
My problem comes here, I know if I want the web interface to be public, I need credentials to connect to the server, such as an Auth key, or username and password. However, in order to use those, then the auth-key would need to ship with the game as a file, or would need to be written directly into the codebase. I know that users can decompile games, and access these files and get the credentials if I include them, which means that option is off the table as far as I am aware.
It is my understanding that even with this layer between the database and the client, someone could still find the url for the interface between them, and then send custom function calls to this url as I will be doing in the game program. Wouldn't this lead to the same conclusion as having the database be open?
If anyone has answers to this, or resources where I can learn about this process, please let me know! I have never done server-side programming before and have also never thought about security before in my life.
You're correct in that you should not embed authentication keys into your apps. Where you're falling down is in exposing your database to the world. Don't do this. Instead, hide it behind a web server that serves only json data files. This way you can take advantage of the web server's authentication and session protocols.
Since you're already working with C#, I would suggest looking into ASP.NET Core MVC and specifically about WebAPI. But I would probably recommend node.js for lightweight microservices.
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I have to come up with an integration process to allow existing system to use external data providers. The system is a medical timetable web site, using ASP.NET MVC, that allows the patients to schedule their appointments to doctors.
As far as I go you can see on a figure below:
All the providers must expose my contract ISuperIntegration which will be develop by me. I won't be developing External service 1 and External service 2, they will be developed by other companies.
Here the issue comes: basing on the concept of that I could require the way providers should setup their services to communicate with my website properly, I want to forbid for another third party clients consume "External Service 1" and "External Service 2", Or at least make it difficult to do that.
Here is a list of stuff I am setting:
ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
And could define some general recommendations but they could be easily avoided.
At the moment I'm thinking of using HTTPS with certificate authentication. It would require the implementer to setup their infrastructure so my web site could properly consume the data.
If I would go with basic HTTP, the implementer would just leave their service to be easily consumed by anyone else, which I don't want.
I hope my question is clear. Will be happy to give any other explanations you want.
I'll really appreciate any your responses, commits. Thank you!
I'd always use HTTPS for things like this. Let's just say that's the cost of doing business. You simply cannot have anyone with a sniffer grab that kind of traffic out of the sky. There's a reason why all banking etc. use HTTPS for things that should be secure.
Apart from that, web services have pretty standard mechanisms for security, I'd recommend looking at OAuth over HTTPS. There are plenty of implementations for that.
If your talking about basic web sites, I'd use a standard security mechanism as well like group based security (which boils down to a username + password). Again, there are plenty of implementations for that.
Basically my main word of advice is: don't go inventing stuff when it comes to security. If you're not an expert, you're probably going to get it wrong, and end up with something that can be intercepted by a third party or (much) worse.
You have several options:
Basic authentication over HTTP.
PRO. Easy to implemet
CON. UserCredentials was going in clear text throuh the network
Implement WS-Security with WCF. For example, they can sign their requests.
PRO. Easy to implement with WCF
CON. Java clients can faced with problems
You can force clients to use HTTPS.
CON. You should setup your web server.
You are like Oracle, they want people to develop in Java language but they also want to forbid competitors to run the Java compiled code on non Oracle's virtual machines, or at least make it difficult to do that :)
So you can do the same by protecting your interface with patent or copyright law. However, I doubt that it is patentable or copyrightable :)
Considering the privacy sensitivity of the data, IMHO it must be encrypted while in transport. Hence HTTPS not HTTP.
Authentication of your service to those providing services to you: well essentially it's up to them, not up to you who they expose it to, similarly how they want it protected is their call. Now assuming you do have a way to make them do the right thing...
Client certificates aren't that expensive nor prohibitive in setup to get up and running. But you do need to register the client certificate (every time it is renewed!) with the server in order to get the needed authorisation (just recognizing it's a valid cert isn't enough: anybody can apply for a (validly signed) certificate ...) .
But all that is relatively painless and rather well documented around the web, and it can be done on almost any platform of choice.
As several people mentioned these earlier you can't guarantee that those external companies will expose your service with specific security settings, it's up to them.
If you are responsible for developing MVC application and WCF service you can only force someone to use specific security settings on the layer between your WCF services and those External 1 and 2 providers.
Btw, here is a good tutorial that can be useful if you want to improve your knowledge about how to configure WCF security.
How External Services expose your service it's up to them. Just image that this is normal web 'proxy' behavior.
Maybe the architecture which your company adopted it is not the best for this solution