I'm trying to authenticate a desktop application with OAuth. I already asked a question, but I deleted it as I discovered that the method was obsolete (integrated web view).
The idea is to open the browser and then have the page call back my application with a custom:// URI scheme.
Of course it doesn't work, Google asks that the scheme contains a dot (like com.org.myapp), but the native app can only have a fmp:// uri scheme, which I can't change.
The documentation doesn't mention anything, and I can't create a local temporary server.
1- Can I use the fmp:// scheme as a callback in any way?
2- If not, is it possible to redirect the call to another centralised web server? Everything I try generates a 400 error on the google page, saying "redirect_uri_mismatch" or similar stuff.
As stated in the comments above, the only solution is to create an intermediate web server that serves a page which then opens the URL. OR creates a record in the database with the authentication code.
Related
I read all similar questions without arriving to the point.
I have a node instance and it runs on my "index.js" only in my local machine.
I have to take a cvs and put on new google sheet.
I have "credentials.json" in my project. Google say me "incorrect redirect_urls". But I cannot put a redirect url since it's a node script.
And I do not want to pass in a browser for a login. This because maybe tomorrow I will put the same script on a real server.
If you are trying to use the Google Sheep API I'm pretty sure you are not getting the results you want. ;)
Assuming you have enabled the Sheets API in you project, and you plan to use a server to deploy the application, then you need to configure you consent screen accordingly.
During development you can use localhost as a redirect URL, which will enable you to test the app.
You should have a read through this help article to correctly set up your OAuth credentials and consent screen for each type of project.
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
I have build a simple web app using Worklight.
My apps Preview URL is :
//local.loc:9080/Mobile/apps/services/preview/MobileAPP/common/0/default/MobileAPP.html
Shortend URL (with bit.ly credentials) is: http://bit.ly/153qbvr
Here the domain is completely different (bit.ly).
But actually I am looking for URL like : http://local.loc:9080/Mobile/MobileAPP.html.
Are there any ways to get a URL for public access like:
//:/application-name/launch_App_.html
if not, let me know ways to reduce the URL - if any.
The first URL you've mentioned is internal. It is meant for preview (development time mostly). Why would you be interested in shortening it? What is the value of doing so for you?
Also note that the shortened URL provided by bit.ly when using this service via Worklight - IS NOT the same URL as the first one (preview), it is meant for the Mobile Web environment, meaning for users who use their mobile browser app to access your app.
In short (no pun intended...), no, there is no way to do what you are asking for via Worklight - you cannot tweak the URL.
Let me re-iterate, the preview URL (the one mentioned in your question and that you want to shorten) is for the administrator or developer. It is NOT MEANT TO BE PUBLICALLY USED in any capacity, shape, form.
If you want to provide a web-public link to your app, add the Desktop Browser environment to your application. This environment is meant to access the app from a regular Desktop (PC/Mac) browser app. Note that even in this case, you cannot shorten the URL via a tweak in Worklight.
What you can do, is install some custom shortening service of your own in your company's servers and create your own custom URL that will look the way you want it to.
I'm trying to use Instapaper's Simple API (http://www.instapaper.com/api/simple).
The API terms of use (http://www.instapaper.com/api/terms) says apps should not store user id and password, and I don't want to store them either. However, it seems that the only way to add a link to a user's Instapaper via simple API is to store the username/password (if the user does have a password).
Am I missing something?
The API terms of use state that:
Apps must not store users’ passwords. Passwords may only be collected for the xAuth token acquisition and must be discarded afterward.
Only the full API uses xAuth tokens. The above sentence doesn't apply to the simple API, since it uses Basic HTTP Authentication.
You still "must make reasonable efforts to prevent passwords from being compromised, and must not disclose passwords to any other services or individuals".
If you are using a native Mac application (like Apple’s Mail client or a third-party mail client like Airmail) there isn’t an easy way to save a link to Instapaper without first opening the link in a browser and then using one of Instapaper’s browser extensions to actually save the article.
One workaround that I’ve found to expedite this task is to write a service for OS X which uses Instapaper’s API to save links.
In order to write your own service, first open Apple’s Automator application and create a new Service. Then, drag the Run Shell Script action into the application’s main workflow area.
Make sure the service receives no input, can be used by any application, and that the shell script is set to run python.
I'm using Java with Google Plus API. I'm using OAuth 2.0. When a user is authenticated, an access code is returned in a browser. Now, given that the code must accompany a call to the Google Plus API, I currently have to manually copy the code and use it in making calls to the Google Plus API. What I wish to do, however, is to programmatically retrieve this code; eliminate the manual copying.
Any assistance will be highly appreciated. Thanks in advance.
It sounds like you're writing a command line or some other non-web application that uses the Google+ API. This throws a little bit of a wrench into the token delivery via HTTP redirect. Without the redirect there's no way for the OAuth web pages to communicate with your code and hence you must copy and paste it.
There is one work around that seems to work pretty well. You can set up a local web server, such as an embedded Jetty, and complete the OAuth flow by redirecting the user back to their locally running web server.
You can see an example of this implemented in oacurl which is hosted here: http://code.google.com/p/oacurl/