Am I able to get the current call history with the call number and DateTime details from the phone with the Mango API? I think it is not possible with the current one.
There is no API to retrieve Call History. This is mainly due to privacy concerns and protecting the user from nefarious applications behaving badly on the device.
You will notice that among the API is a collection of Launchers and Choosers. One of which is the PhoneNumberChooser Task. This particular task launches the Contacts application and allows the user to physically select a contact number to dial from your application. You'll notice this requires a manual interaction from the user. Many of the data retrieval APIs require manual selection from the user, once again to protect the user from applications doing bad things. For example, trolling your contact list in the background and sending that data to a web service without the user's knowledge.
Special care was given to the API's to protect the user from these types of scenarios.
If you have feedback on the need for an API to provide a Call History Chooser, submit your feedback to http://wpdev.uservoice.com.
If Marketplace screens apps for behavior, and if apps have to declare what they do, and if users have to opt in to allow an app to get access to this information, it would seem reasonable to give app developers and more importantly users the option to decide this. And if there is still fear about this, then the OS could pop up a user response screen to permit or deny the action when an app requests to do so. There are many applications that could benefit from knowing this information to save the user from having to enter information from the current call when it could be easy for them to permit an application to get the data.
Related
I'm trying to create a program that sends messages to groups from time to time. If I'm not mistaken, the only API I see that send messages is "Create Post" which is the "Team Messaging" section. This API uses Glip permission. The test messages that I was sending is being sent to the developer Glip-App account, when I logged into the Glip-App account, the page didn't look like the regular RingCentral app. The UI is different. I have a feeling, that I am working on the wrong API.
I also have few more questions. My program is only required to send messages, but in order to apply for production, I have to practice other API calls as well, such as Get, Delete, Update etc. I'm not sure why it is like that. Also, I had to practice all the permission given, but the only permission I have given is Glip and it's still in the red.
Finally, the test messages that I've sent, showing the user's actual name on the Glip App page. Is there a way that I can use an alias?
The test messages that I was sending is being sent to the developer Glip-App account, when I logged into the Glip-App account, the page didn't look like the regular RingCentral app.
There are two developer sandbox accounts for RC App now, one for the new App and one for the legacy app. At this point, you should be using the new URL. The legacy URL still exists for testing purposes and will be retired at some point in the future at which time the URL should redirect to the new URL.
New: https://app.devtest.ringcentral.com/
Legacy: https://glip-app.devtest.ringcentral.com/
My program is only required to send messages, but in order to apply for production, I have to practice other API calls as well, such as Get, Delete, Update etc. I'm not sure why it is like that. Also, I had to practice all the permission given, but the only permission I have given is Glip and it's still in the red.
This should not be the case. Please contact the support team regarding this.
Finally, the test messages that I've sent, showing the user's actual name on the Glip App page. Is there a way that I can use an alias?
If you are posting using the credentials of a user, the user's name will show up since the user is being represented, not an app. You can also post into a team using a webhook or chatbot in which case other names will appear.
I am creating a .NET class library which will allow local applications to access the accounts of users registered on my website, using an API. I would like the library to handle all authentication of users, so that any app I create an simply call the library, and be returned a token for the API. I'm not sure how to do this authentication.
There are a couple of ways I have considered doing this, however they are not ideal. The first would be to simply create a login form within the library which asks users to enter their login then calls the API. The second method would be to have a webpage where the user logs in and is then given the token which they enter into the app.
The ideal scenario for this situation is that the user does not see their token, and the actual login process is delegated to the website if possible. Both of the above ways lose out on one of those conditions.
The ideal way I would like to do this is inspired from an app I use where if the user is not logged in, they must press a 'Sign In' button, which opens a webpage where they log in. Once they have done so successfully the app automatically detects this and they are signed into the app. The downfall of this solution is that I have no idea how I might do that myself.
Essentially what I'm asking is, is the third solution viable, and how could I do it, or if not are there any better solutions I've overlooked.
FYI the website and API run ASP.NET MVC and WebAPI respectively and the library will use .NET framework.
Edit:
From the comment below it seems likely that you'll want to implement an authentication provider using something like OAuth. The .NET reference libraries can be found here and there's a similar answer already on StackOverflow that may also shed some light.
Welcome to Stack Overflow!
Personally, I would keep the Web API as the authority on authenticating a user and just consume this HTTP endpoint on all platforms (web, desktop, mobile etc) whenever you want to validate a user's credentials.
At a high level the process would be along the lines of:
Have your "clients" (desktop, mobile, web applications) submit HTTP requests to an API route (something like /authenticate) when the user first logs in.
Run your authentication logic
If successful return a token (and cache this this for use in subsequent requests)
Otherwise return a 401 response
Every client will now get a standardised response they can use for determining if they should redirect the user to some protected area, or show them an error message.
This also allows you to design login screens that are native to the platform they're running on (which is a smoother user experience). I wouldn't recommend having a library return a pre-built login page to the user - you'll find that becomes a real pain to maintain!
The third solution you proposed is also a valid way of doing things - but it does have the side effect of redirecting the user's focus away from the application they're using - which you may not want depending on your use case. It's also a bit trickier to implement than just calling the API directly, so unless you have a specific requirement to do it this way I'd not recommend it.
Hopefully this makes some sense. If you are unsure on how to implement cross application authentication then I'd recommend taking a look at some existing answers on Stack Overflow such as:
Basic token checking
OAuth
Typical case of making a simple application, boss likes it, sysadmin wants to be able to configure it.
I made a simple login helper application to assist my team members with logging into a pile of different websites/tools in the morning. You create a list of sites, enter your most used password, it logs you in (and prompts for a password for sites with a unique one). Gif here: http://i.imgur.com/0HIVbMw.gif
The sysadmin at my facility has requested that I store the list of websites in the registry and make it available for management via Group Policy (So that the list can be pushed to everyone, and limited in some way). I'm going to be honest, I know nothing about Group Policy. I have heard that storing data in teh registry is not always the best option.
How can I make my applications setting and/or data configurable through Group Policy? Do I need to store it all in the registry? What options do I have that can give our sysadmin the control he desires?
Edit: Can a config file be pushed to the profiles of all users that the application can use?
I haven’t really worked a lot with AD, and not at all with FIM, but I’m now in a situation where we as a team need to provide some options for a customer that would like to have a self-service system for password reset. FIM is already in place and being used for some synchronization things, and it has been decided that we will be using FIM. The question is how.
Here is the ideal
A custom application that is accessible from:
After login in a browser
On an external device
From the login screen (see separate discussion on this)
We are using the following to identify the users:
ID (work)
Security questions
Magnetstripe card (optional)
Personal details
We are considering SMS identification as well, but only 20% of the users have a registered phone
Here are the options we have come up with so far, with our thoughts:
FIM out of the box self-service works and provides a login screen link to change the password – which we really want. The GUI on the other hand isn’t very customizable and doesn’t provide the user experience we want. You can only change colors, fonts and logo. We would like to freely customize the look, and workflow.
Web application that after all required details are filled in provides a temporary password that will require immediate password reset once logged in. Email will notify user about password change attempt, and lock for further attempts ant notify support if more than 3 attempts are made within a day.
This does however not provide a login on the screen, which is a feature we were hoping for. Talks to FIM services on the backend.
SMS password reset service based on the same concept as above. Not really an option since we have few registered phones. Talks to FIM services on the backend.
A login hook that takes the user to the browser to the application (not FIM app, but uses FIM services). The worry here is creating a security risk by changing the login screen, and also how to roll out the solution, and how OS updates will affect us. But most of all, the feedback I’ve gotten from other developers is that this is a pretty bad idea.
Here are the questions:
**
Are we missing some other options?
What should be our biggest concern?
And which option would be best?
** – We define best as the option that fulfills these criteria’s, in order of importance:
Secure
User friendly
Maintainable
Less costly to implement/less time
Any information is greatly appreciated, hope I’ve provided enough information. Happy to adjust the text/question if it’s not scoped clearly enough.
As far as I know, FIM comes with a Self-Service Password Reset Portal.
You can find the documentation (plan/deploy/maintain)on TechNet:
http://technet.microsoft.com/en-us/library/jj134309(v=ws.10).aspx
See also this TechEd talk: http://www.youtube.com/watch?v=T-p41Ze9ewA
--larsw
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.