Josh, One thing you may also want to consider is how you would handle api authentication for institutions that use Shibboleth. There are secure ways to do this, à-la the google 2-step verification or via an embedded browser, but that would involve some additional fields in the database and modification of the web front-end.
The main question in my mind would be whether the application would store these access credentials and/or how a user logs out. I don't see this as a problem for users' personal machines, but if someone tried to use this in the context of a pubic or lab computer, I would be very concerned. If, as Art suggested below, the desktop app required users to authenticate and then be timed out after a set period, then what would be the advantage of a desktop app? Especially if a campus already has some type of web-based single sign on in place. In short, what exactly is the goal in developing a desktop app? If the goal is to bypass the standard VCL website and simplify access, you can use the existing API to do that. I have written several web-based "alternate interfaces" for our VCL that function well, including one that integrates with our campus' learning management system. They are easy to write and the developer has full control over how they look -- that would be harder to accomplish with a desktop application. The existing API is certainly more limited in its range of functions when compared to the full web site. On the other hand, it is capable of making and managing reservations, which constitute the vast majority of users' (esp. students') interactions with the VCL. You can see some screenshots here: https://vcl.ats.amherst.edu/remote_access/ On the other hand, if the goal is to eliminate the somewhat awkward transition between the VCL website and an active RDP connection, there are ways to deal with that, too. With the use of protocol handlers and a little bit of custom application development for Windows, we have a working "one-click logon" solution that works on all of the major browser-OS combinations (IE, FF, Safari, Chrome; Win7, WinXP, OS X, Ubuntu). And this pairs nicely with the remote interfaces mentioned above, making it really simple for users to connect. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Feb 8, 2012, at 2:08 PM, Art Vandenberg wrote: > Georgia State is likely interested in this IF it doesn't reduce security. I > presume icon would be clickable and then one VIOLA, logged in? If so, there > is presumably no login per se. Perhaps some time-out on the ICON would be > valuable then - e.g. you have "x minutes" to click or else (something > happens... goes away? expires? prompts for PW after all?) Maybe recommended > only where there is at least some login (to VCL menu at least) so there is a > reasonable accountability? > > > I am going to send this to our engineers and ask for their input (I think the > read the posts, but will be direct.) > > Art > > > On Feb 8, 2012, at 11:56 AM, Josh Thompson wrote: > >> I've been hearing interest in an "icon on the desktop" type of access to >> VCL. The idea being that you could have some kind of broker script/app that >> can be run which will interact with the VCL API to create a VCL >> reservation, wait on it to be deployed, and then connect to the reserved >> system (ideally without requiring the user to log in to the reserved >> system). That app could then just be launched through an icon to gain >> access to a VCL provisioned system. >> >> Several years ago, I wrote something along the lines of this in python/tk. >> That was more of a proof of concept and would need a good bit of work to be >> useful to others. >> >> I'm starting this thread to start gathering information on who is >> interested in this idea and what requirements you would have for it. I'd >> also like to know if anyone would be interested in helping with the >> development of it. >> >> So, if you have any interest in this, please reply to this thread with >> -requirements you would have >> -how you would envision it to work >> -any interest in development of it >> >> Thanks, >> Josh >> ------------------------------- >> Josh Thompson >> VCL Developer >> North Carolina State University > > Art Vandenberg > Account Manager/Research Function > Customer Relations, IS&T > Information Systems & Technology > Georgia State University > avandenb...@gsu.edu > +1 404 413 4743 > MS Information & Computer Science, Georgia Tech > MVA Painting & Drawing, Georgia State > Web page: http://www.gsu.edu/ist/acs/25735.html >
