How can authentication details be passed to a shiny app in a a secure way?
The shiny app is hosted on a a Linux machine with Shiny Server (Open Source version) and should only be accessible after login on another webpage (through SAML) which is hosted on another Linux machine. The shiny app should have different functionality, depending on user rights. So, that information has to be passed to the shiny app at startup.
How can this be achieved in a secure and reliable way?
The only options I could think of were:
Getting the IP-adress of the user and making a request from the other webpage to get the user-rights of that IP.
Passing user-rights within the URL params and using those with parseQueryString(session$clientData$url_search) at shiny-startup.
The first option would make the app depend on a third-party service that gives me the IP and I dont know how a proxy, Vpn etc would interfer with this approach and how reliable it would be. The second option doesn't really seem secure or professional.
What other options would there be?
Related
I've created an app that uses Javascript and php. The php is hosted on an apache server which is located in my house and is not accessible from outside. To start the 'app' I just point my browser at
http://server-ip-address/my-app
The problem I'm having is with SoundCloud Authentication.
If I'm using a browser on the same machine as the apache server then I can authenticate using a redirect URL of
http://localhost/my-app/callback.html
and setting this in the app settings on soundcloud.com and the initialise function in the SDK.
The problem is, what if I'm not running the browser on the same machine as the apache server? The app is a remote control for a music player, hence the server will generally be running on a headless PC and the app will be accessed from another device. There seems to be no way to get Authentication to work in both these scenarios since the URI I send in the initialise function has to match the one on the soundcloud app settings and I have no way of knowing what server-ip-address will be for everyone who might use the app.
Unless you do have a way of locating that server (with static IP or some dynamic DNS service) you won't be able to authenticate – SoundCloud has to pass the oauth_token somewhere.
I have an WinJS metro application that I'm using to connect to a remote webservice that same domain. I read up on the app manifest capability (well the little that is present online) and was hoping that I would be able to use the logged in users credentials to access this webservice without requiring them to login.
I'm trying to authenticate to the webservice via a post using a contentType: "application/x-www-form-urlencoded;charset='utf-8'". This application was previously a website that would prompt the user for login credentials in the authentication step using the aforementioned post. In the WinJS metro application I'm effectively using the same code (minor tweaks) to achieve the same result.
Has anyone had experience with Enterprise Authentication in a WinJS metro application and could better explain what types of resources I would/wouldn't have access to. I'm hoping this isn't specific to accessing things like file shares and intranet sites.
I had this exact issue as well. After ensuring the following Capabilities were enabled in the package.appxmanifest:
Enterprise Authentication
Internet (Client)
Private Networks (Client & Server)
I had to still add the URL of our web service to Internet Explorer's list of Intranet Sites. Only then did the prompt go away.
I'm trying to figure out, how to use OAuth 2.0 to access Google APIs from my web app. The problem is, that the protocol require developer to register redirect_uri (URL of page receiving access token). But my application can be distributed to many customers and can be hosted on endless number of servers. There is no way to know redirect_uri beforehand.
Google offers another option for installed applications, but I cannot use this variant neither. Auth server returns access code in window title and this information cannot be accessed from javascript of our page (JS cannot access content of window opened using window.open(); if that content comes from different server).
To conclude:
Cannot use method for web applications, because I don't know all URLs where will our app run in the future.
Cannot use method for installed applications, because window title is not accessible from our JavaScript code.
Is there any recommendation, how to use Google's OAuth 2.0 from distributable web application running on a lots of servers? Thank you.
Are you sure you cannot access the window title? If your app is opening the window, it should be able to access it. It should be possible to do this in a similar way you would do it in a mobile app.
If all attempts fail, you could set up a proxy server (that has a known redirect URI) and hands out the Google tokens to all your clients. Or better each of the apps could have its own proxy server - the server it was downloaded from. But then if each OAuth client can only have one redirect URI, each app would have to be a separate OAuth client.
I have a project with the purpose of exposing multiple web applications over the internet. These applications are build using IIS/DotNet and Apache/Php.
The internet user should log-in in only one place, and then be able to access any aplication.
What are the posible solutions to this scenario? One requirement is that changes to existing applications be minimum and another is to use ActiveDirectory for user management.
I have found so far the following solutions:
use a reverse proxy (COTS product) to publish web applications to the internet, and the proxy should take care of authentication/SSO
using forms authentication and a domain wide cookie; this solutions requires changes to existing applications and manual log in in AD
create a new application using forms authentication and after user enters credentials into this application, use these credentials to send a XMLHttpRequest to another applications (this will log in the user)
use client certificates, so that when a user connects to an applications, his certificate will handle the log in process; this approach has a problem when there is more than one certificate installed in the client browser because the browser will ask the user to choose a certificate (and this will happen for every app)
We are developing an app that consists of a web server that hosts a web service (amongst other things) and a client that will be communicating with that web service. Both the client app and the server are expected to be used within a corporate firewall. This application will be packaged up and deployed to organizations across the world—so it needs to be flexible enough to work in multiple types of environments.
My question revolves around web service authentication and what is appropriate for real world scenarios. I know some companies have proxy servers that require a separate authentication. How often is this a requirement across organizations? When does the proxy server force the user to authenticate (can you access internal sites without authenticating.. is the authentication for only external sites)?
Reason I ask these questions, is I’m not sure what kind of capability we should build into our client application for authentication to the web service. By default, we are taking the current user credentials and passing that up to the server. Do you think this is sufficient? In a case where a company will require some form of alternate authentication for internal access, this will not work. My question revolves around this last case—how often does it happen? Why would a company force alternate credentials for internal access?
Thanks!
Why not make it configurable? Further, use WCF and you have the ability to configure just about anything you might need, in most cases without changing your code.
If Internet Explorer can reach a site through the proxy server without prompting the user, your call to the web service should "just work". If the user is prompted by IE, you'll need to put together a way to fill in the proxy server authentication information.
I've run into quite a few problems getting web services rock solid, but never had a proxy server authentication issue.