Short question this time - is it possible for me to check whether the user has disabled notifications in the notifications/actions centre?
Currently, notifications are sent via MPNS, and work as intended, and the only "issue" is being aware if the user will receive toast notifications or not :)
The only two sources I managed to find so far even remotely connected are the one discussing possible restrictions due to the battery saver, and discussing sending toast notifications from application (which is not what is needed here).
Since MS states in their documentation that we're not supposed to "use your app to ask users to enable toast notifications if they have chosen to disable them. Your app is expected to work without toast notifications.", I feel that perhaps this information is not as freely accessible as it might seem at first glance, but hopefully some of you can either confirm my suspicions or help me overcome it :)
Related
I have no previous experience with programming Google Chrome plugins which is why I am starting here to see if what I want to accomplish is possible/reasonable. I do however have a pretty broad experience in programming in general.
What I want:
I want some kind of "trigger" to go off when a new Chrome Notification (you know these little pop ups above the system tray) is popping up. I want to execute some script/code depending on what information the notification contains so that I for example could have an alarm go off if I receive an email from a certain user with a certain key word in the subject and get a pop up from my Gmail Notifier extension.
This is however just an example and I have a bunch of ideas for different notifications from different extensions and websites so don't get caught up on that particular example.
When I look at the Chrome Notification API I see that there is a getAll method that supposedly is getting all the "notifications in the system" but I do not find any Event for new notifications.
I suppose a possibility would be to poll with getAll a couple of times per second (it needs to be really fast for some implementations I have in mind) but it feels very tacky.
Is there any way to easily access new Notifications programmatically in Chrome?
(I'm open to all solutions, programming languages and such...)
Well, I searched long and hard and got involved with the Chromium dev group and asked around there. As far as I could figure out there was no reasonable way of accessing all Notifications programatically.
So what I ended up doing was just download the source-code of Chromium and build my own custom version of chromium adding a very crude API. Worked like a charm and not as complicated as one might think.
Cheers!
Does anyone know why Box.com make it so hard to generate an authorization code programmatically? I wrote some code to do this through screen-scraping, and then recently this broke because (as far as I can tell) one HTTP request parameter changed from [root_readwrite] to root_readwrite. I was able to fix it reasonably quickly (thank you Fiddler), but why make developers go to this trouble?
Judging by the number of questions on this topic, many developers need to do this, presumably for good reason, and I don't think it can be prevented, so why not just embrace it?
Thanks for listening, Martin
The issue with doing OAuth programmatically is that it would effectively defeat the point of OAuth. Users are supposed to be presented with the Box login page so that they never have to give their username and password directly to your app. This allows users to see what permissions your app has over their account (the scope) and also allows them to revoke your app at any time.
Doing login programmatically means that at some point your app knows the user's password. This requires that the user trusts you to not do anything malicious, which usually isn't feasible unless you're a well-trusted name. The user also has to trust that you handle their credentials correctly and won't use them in an insecure way.
Box wants to encourage developers to do authentication the correct and secure way, and therefore isn't likely to support doing OAuth programmatically. You should really try to perform login the supported way by going through the Box login page.
I would like to publish an app in google play, but I want to restrict the downloading under password or something like that. Is it possible? Is there any alternative?
Many thanks in advance,
Short Answer:
No.
Slightly Long Answer:
Applications available on Google Play cannot be downloaded only after a user authenticates. Any such feature will have to be implemented withing your application. At best, if this feature is needed for monetary reasons, publish a paid application.
Since the OP isn't descriptive beyond what you are looking for as a feature, it will be difficult to suggest an option / alternative that might suit your requirement. However, if you have a server setup that can communicate with the app, you can implement a feature which requires users, upon installation and running your app, to Sign Up for a new account and/or Login if already registered.
Again, I will circle back to the original point. Any such feature will have to implemented within the application itself. Google Play does not have such a feature.
The documentation (http://developers.box.com/webhooks/) talks about webhooks in the context of "user's account". I read that as getting notifications only about the objects to which I have access.
Let's say I want to be notified every time there is a new upload anywhere across my organization. Do I need to be an admin to accomplish this, or is the webhooks scope not subject to my user permissions?
While we're continuing to enhance webhooks, there is some administrative functionality built-in. For instance, if you can get your webhooks installed for all your users, and have the webhook point to one endpoint, that can track all activity in your account.
There is a way to force webhooks on all users in your domain as an administrator. However, this feature hasn't been optimized for companies that use webhooks for internal use. That's still in progress.
If you'd like to be kept in the loop, or try some workarounds with what we have, feel free to contact us at api [at] box [dot] com. With more information, we may find something that works today, based on your exact needs.
At this point, the webhooks are only provided at the user level. If you log on as an admin and setup an application that gets webhooks, you will only get the same set of notifications as you see in the "Updates" tab in the Web UI.
We are looking to expand the webhooks capabilities, and this is one area that we may explore. However, it is not currently scheduled, so I can't provide any idea of even rough dates.
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.