I am writing an iOS app that will use data from Skype for Business, and am following the guide from Microsoft called Create an application, which must be done before being able to use the API's.
What is unclear to me is when exactly to create an application? Is it:
per client, i.e. only once ever?
per home server?
per user?
per session?
The application here is more a kind of "virtual object (the application)"
which needs to be created here, until you can start using Skype for Business (SfB) features.
So your question isn´t that easy to answer as its not clear what you wish to perform (e.g. did you wish to login, perform some task and then logoff again?). So it depends a little bit on your application and which features you are using. Therefore its no "only once ever" as the "virtual object (the application)" is destroyed at some time (e.g. your application crash and the SfB server no longer got a "yes we are still here and are listening" requests). This is controlled by the lifetime of a token which is eight (8) hours for authenticated users so you need to renew that or your application will stop working. So its more a "per taskuser & login & time" approach...
Microsoft explained the above as well in the following statement: "This is how you register your application with UCWA 2.0 as an agent of the user whose credentials you obtained in a previous step."
If you are creating an iOS application that will interact with a Skype for Business server, you can use the Skype for Business App SDK for iOS. This client library handles anonymous meeting joins for users who are not homed on a Skype for Business server. For all other Skype for Business features, you'll need to use an iOS REST library of your choice. The REST endpoint that works best for a client application is actually the Skype Web SDK. The Skype Trusted Application API is designed for server-to-server communications where your server is talking to a Skype for Business Online instance. In that case, your server obtains and processes Skype data and then it makes it available to a client such as an iOS app. Unless you intend to create a middle tier between Skype for Business Online and your iOS app, you should use the Web SDK.
Related
Since there are a lot of APIs for Skype for Business, and the documentation isn't always very clear, and many hours have already been wasted developing for an wrong API, here I am asking you:
I am looking for an API which enables me to administrate multiple Skype for Business Online users. Required Features:
Skype for Business Online compatible
Read and Set Presence from other users
Set Call Forwarding for other users
And all that without knowing the user's passwords.
I already started developing for UCWA until I realized every user's password is needed for setting the presence.
I am aware of the capabilities of an UCMA Trusted Application, but unfortunately S4B Online compatibility is required. Maybe it's possible to make it compatible with an interface?
Every thought on this is much appreciated.
This would have been possible with on premise Skype for Business:
A trusted UCMA application to read and set presence
Automating SEFAUtil to set the call forwarding options (which relies on UCMA)
Unfortunately (as you rightly said), neither of these are supported against Online, as there is no direct replacement for UCMA. There's unlikely to be a replacement in the future as Microsoft are pushing to move customers away from SfB and on to Teams.
Depending on exactly how you need this to work, one option would be to use the Lync 2013 client SDK, which still works against the SfB client (but is now out of mainstream support). You'd need to create a "hidden" application that gets deployed to the users desktops, and sends and receives commands to/from your centralised administration app. In that way, you'd be able to send commands to the user's application, which would then automate the client into setting presence and changing call forwarding. Some obvious downsides, though:
A lot of work to build out the client/server applications and manage the connections between them
Would only work when the user is signed in to their client (as the Client SDK uses the running instance of the Skype client)
Depends on being able to deploy to a client machine
Not an ideal solution, I know, but with Teams replacing SfB Online (over time), your options are going to be limited!
I have a mobile application which relies on a Windows Azure App Services Back-end. I want to tie down some security vulnerabilities. For example, someone can currently access all my records, modify or delete them. Not Ideal...
I only want users to be able to access their own records (data privacy) and I want to ensure that only my application can POST data to the server, i.e. an unofficial potentially corrupted app shouldn't be able to POST data and corrupt my database. Maybe some sort of TLS etc. approach might do this? This restriction (if possible) would likely allow me to implement the access-to-own-records-only logic in the mobile app rather than backend?
How could I ensure only legitimate versions of my app can interact with my back-end?
Azure Mobile Apps (an SDK on top of a standard Node/Express or ASP.NET app that can be deployed to Azure App Service) provides a mechanism that your web or mobile app can access records in a SQL database. The users ID is stored alongside the record on a POST and the users ID is also used as part of the query when returning records.
See https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/ - particularly Day 6 (for Node/Express) and 18 (for ASP.NET)
As to your last question - how to ensure only legit versions of the app can interact with your backend - you can't. Trivially, you might think to use a shared secret that needs to be passed IN ADDITION TO other authentication requirements. However, this does not stop someone sniffing the wire and using the same shared secret. There is virtually no way that you can stop a determined player from accessing your backend without using an approved app.
I want to know which user is logged in multiple Lync client in different machines.
So how should I get to know and which SDK will gives this details?
With either UCMA or Lync Client SDK you can determine if one or more clients are logged in using presence subscription. This will give you a simple "there is a endpoint running somewhere or not", but that's not what you are asking for.
As far as I know, there is no way to do what you want with UCMA or the Lync Client SDK.
You can do it with the Lync Server SDK, but it will take some work. You can do with either a MSPL script (limited) or MSPL/C# proxy application (more options) that filters for REGISTER requests/responses.
From the register request you can determine if it's a register (coming online), unregister (going offline) or re-registration (replacing existing registration) by the expires header / contact uri expires parameter (0 == unregister).
You can determine the user type by the user-agent header, mainly between Lync Client (e.g. "UCCAPI/15.0.4771.1000 OC/15.0.4771.1001 (Skype for Business)"), Lync Phone, UCMA endpoint (e.g. RTCC/5.0.0.0 Xxxx).
You also need to handle registration timeout and re-registration.
With this knowledge you have a running knowledge of what user agents are running for the users you wish to track and do with what you wish.
So if you really want to do this, I would as a prerequisite to starting:
Get familiar with sip messaging.
Play around with building / running the examples in the Lync Server SDK.
MSPL will be a solution, but that will ask you some work like "Shane Powell" said.
The most easy way will be to use Powershell...
I use for my part "Get-CsConnections" from ehloworld.
Is a powershell script who it will shows you all the details of connection about any users.
I would like to use cloudfoundry to demo a Spring-based webapp to a limited group of beta testers.
I can't really rely on the application's own authentication/security mechanism as it is already used by the business logic of the application (i.e. a visitor to the website can register as a new member and then login with an email and password).
I therefore need some way to restrict access to my beta website to a limited number of beta testers who will need to "pre-authenticate" before they can navigate both the "public" and "private" part of the beta website.
Is this possible with CloudFoundry? If so how?
No, currently it is not possible. As soon as you've published your app to CF and registered a rote for it, it becomes publicly available to all internet users.
The authentication mechanism that CF provides is for management purposes (e.g. creating a user that will be able to push new version of the app to CF) and is not connected with the business logic of your application.
CF only provides abstraction from a hosting platform according to PaaS approach. That means that your app will implement all the functionality it needs, including authentication.
However you could use some standard features of your framework to achieve this, but still you is the one who is responsible for it.
I'm building an application which uses last.fm API. I want my server to communicate with last.fm and the users of my application would communicate with the server. So the user is indirectly communicating with last.fm. I'm doing this to speed up the whole communication by caching some data on my server.
Is this OK?
As long as you follow their TOS, you are OK.
Yes, this is OK. Many other services do this.
If you think about it, any action any app takes is always indirect. There is no requirement that the application acting on behalf of the user runs on the same computer as the user. Quite often the application runs on a web server.
Some examples of apps which do this include http://tweekly.fm/ and http://hypem.com/ .
In order for the service to act on the user's behalf (for certain methods such as scrobbling), you have to authorise your application as the user, and this is achieved using the web auth flow described at http://www.last.fm/api/webauth .
(This is one of those flows where the user is directed to a page on Last.fm to confirm that they authorise your app. Your app receives a session key in return, which allows your app to act on behalf of the user).