I have written a click-once deployed application in .Net that runs on windows machines. I had a requirement to launch the application from a browser so that I can pass information to the application based on the current browser session (the HTTPHeadercontains a single-sign-on id that needs to be passed to the application so it can call secured web services).
So the click-once application is provided as a link on a jsp, and the required id is passed as a querystring parameter in the link, which the click once application can read).
Now I need to make similar functionality available for Mac users. Is there any way to do this that doesn't require Java? I would like to write in Objective C, but then the question of how to trigger the launch of the application from the browser, passing the necessarily information remains.
The flow is:
User hits link to our site
User is routed to single sign-on authentication form
User submits form and is redirected to our site (with id embedded in HTTPHeader)
Server builds page with a link to Click Once application with id appended as a querystring parameter
User clicks link, click once deployed app is downloaded and executed with full trust on the users computer (the app is signed with a code signing cert).
Application runs locally on users computer and calls RESTful web services on server passing the single-sign-on ID as a cookie along with the web request which allows the request to make it through.
I would appreciate any ideas that point me down the right path, as I am primarily a windows developer.
Thanks!
I just saw your request to my original post on this topic.
The need for this was put on the back burner for a time, but the solution that we will probably pursue is to have a server-side process that modifies the delivered Zip or DMG file on-the-fly. The additional information would be inserted into the application's Info.plist file. This will not invalidate the cryptographic signature, and does not require anything additional to be downloaded.
Related
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'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.
Couple of questions:
I implemented the authentication process with OneDrive. My desktop application is designed for end-users. Every time the application is launched the little browser window pops up asking the user to confirm access...and if more than 1 hour passed user needs to provide username and password. Is there any way that end-user with SOME SORT of saved credentials (or user Code +user Secret, or API code + API secret) will be able to invoke the application and not be prompted by browser form (that currently requires login - if access token expired - or confirmation)?
The goal of my application is file sharing - that is, one end user may send URL (to the file that he uploaded to OneDrive) to another user and the latter should be able to download the file by clicking on the link (without any prompts, exactly like in manual process of sharing link to the file in OneDrive). Is it possible? If yes, how to achieve that? That is, how do I get that URL? Redandent to say that I am looking for a programmatic way to obtain a URL that will achieve the above described)
The OneDrive authentication process uses Microsoft account, which supports OAuth 2.0. You should be able to point the user to:
https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPE&response_type=code&redirect_uri=REDIRECT_URI
Once the user authenticated and authorizes your app, the user will be taken to REDIRECT_URI/?code=CODE, where your app can exchange that code for an access token at:
https://login.live.com/oauth20_token.srf?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&code=CODE&grant_type=authorization_code&redirect_uri=REDIRECT_URI.
There are more details at http://onedrive.github.io/auth/msa_oauth.htm.
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.
We have a Add hoc distribution for enterprice apps by a secure website. Since version 5 we have a problem with authentication in combination with IIS7. The user logs in with a windows username and password and clicks download. Then a "itms-services://?action=download-manifest&url=domain" action is been started.
Before IOS 5:
The user goes to url, types the username and password. The user press download and again the user need to type the username and password. The application is been installed.
After installing IOS 5:
The user goes to url, types the username and password. The user press download and get a domain "...." not found. There is no popup again, with the credentials, like before version of IOS 5..
This solution was working for a half year, but since IOS5 it doesnt work anymore...
IIS Log
When going to the website and clicking on the action=download that contains the Plist file the IIS shows 401 errors (not authenticated). But when I access the .plist or ipa file directly by url in safari I do get a POPUP to authenticate.
It look like there is a bug in IOS 5 "itms-services://?action=download-manifest&url=domain" actions does not support to authenticate....
Check your plist file if it points to an existing ipa file. If you're using .htaccess to authenticate with a ldap directory you'll need to authenticate once for the plist access and once for the ipa access.
This sounds like a variation of the double-hop problem in which the originally supplied credentials are not being appropriately passed to the second step in your download routine (or web service call, etc.). http://blogs.msdn.com/b/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
The fact that you previously had to enter the user name and password twice would seem to support this suggestion. The error that you're receiving that domain '...' does not exist could indicate that the credential being passed to step two is a local machine account that IIS is running under.
If you can get some logging on this process I would want to determine what the authentication/credentials are that get passed at each step. It's possible that something in IOS 5 changed the way that impersonation is handled but I think that's likely just a symptom of how either IIS is set up or the final request is being passed.