I created a DotNetOpenAuth MVC 2 project using the visual studio template, and have it working. However, the sign in page takes a long time to load. Not quite sure exactly what is going on in the library, but it seems like there is some kind of javascript slowing down the login image button UI from rendering quickly.
I'd like to instead use the openid-selector on the client, rather than the MVC helpers from the DotNetOpenAuth library. What kinds of client & server hooks is the HtmlHelper in this example hiding?
This post shows how to integrate DotNetOpenAuth and openid-selector:
http://blog.tchami.com/post/ASPNET-MVC-2-and-OpenID.aspx
The openid-selector client, if you're talking about the one like StackOverflow uses, has no server-side hooks at all in the same way that the HtmlHelper's in DNOA use, since the openid-selector makes no AJAX calls back to the server. DNOA's selector control uses AJAX a lot to provide users with an auto-login experience, auto-discovery as they type in the identifier, etc.
So in short, yes, the openid-selector (SO-style) is much simpler and works great with DNOA as well.
And yes, DNOA's built-in AJAX selector loads more slowly. That's something that I (or a volunteer) still need to work on speeding up.
Related
I am developing a single page app running in desktop browser, tablet browser and maybe phone browser. I am return only JSON from my backend wether it is ASP.NET MVC or Web API.
When I think of Web API or read about it I always hear the words REST/RESTfull. Independently from what REST is I like some features about Web API which I have not in MVC (by default but maybe it can be implemented somehow but I dont want that extra effort...)
Return HttpStatus codes like 200 for GET or 201 when the Ressource is created. My single page app knows and reacts on this codes.
Return DTOs directly in the controller and c# classes are automatically serialized to json. With MVC this is not a one-liner. Not dealing with ActionResults.
Web API is very much designed about 'cool' urls/routing I will also have deep/complex routing on my client.
My Web API endpoints are just 'ajax callbacks' I do not need REST things like include a self.link in every retrieved ressource etc...
Of course I do not create/modify ressources on a Get request. But I already have been used to this style when I was doing MVC. So I like and will do many REST styles but not because of REST itself rather its common practice.
Should I really design great restfull API`s to use the Web API ? I do not know what is Microsofts recommendation about the Web API or wether they have really a guideline about it...
In my experience Web API has often been a great help, and rarely a hindrance. If you do it "their way," it saves you a lot of ugly work around serialization/routing/binding. If you don't want to do it "their way," you don't have to. You can extend the routing engine. You can implement your own serialization. You can return raw JSON where you see fit. Nothing in Web API forces you to follow the REST concept to a T (trust me I have seen this in action). I haven't heard this complaint before from anyone who has used it - I would suggest you give it a try and see just how far off it really is.
REST is not at all required to use Web API. In fact, it is quite easy to turn on and use session management as well.
In fact, while RESTful approaches have some real advantages, I wouldn't recommend going 100% RESTful. It is simply not possible to make them fully secure without using a third-party authentication provider. We built a fully RESTful prototype and explored many different mechanisms to secure the site. In the end, though, every one had one vulnerability or another (it helps to have a CISSP on staff). So I talked to one of the top security experts at Norton and he agreed that, yes, there is always a way to exploit a fully RESTful, standalone app. Symantec is apparently building a "wrapper" technology that gets around this but it was easier to either go with a third-party authentication provider or just go back to MS-based security using session cookies.
I have been implementing a skeleton Claims Based architecture for our services and websites. I'm using WIF, .NET 4.5, MVC / Web Api.
I have the STS (WS-Federation / WS-Trust) and several Relying Parties implemented, and all is working fine.
Now, I want to be able to authenticate in one Relying Party and use that same token (the bootstrap token, I assume) to make Ajax calls to another Relying Party. I can get the Bootstrap Token down in the HTML (is this even a good idea?), and add it to the Ajax call headers as some form of Authentication (Basic, etc).
What I don't know is how to intercept the request in the final Relying party, and "tell" WIF to use that bootstrap token and do it's magic with it (Load, Validate, Authenticate, Authorize, Create Principal, Create Session Token, Write it down in a cooke).
I guess I could do all this by hand using the available classes, but there must be a point where I can just hook up for this. Probably around the SAM / FAM modules, but I can't understand exactly how.
Any ideas?
Thanks
SAML is not a good fit for being consumed in html. The format is complex and relies too much on WS-Security for cryptography. I see more adoption these days of OAuth2 (It was OAuth-Wrap in the past), although is complex as well. If you want to explore that path, I recommend the ThinkTecture Identity Server as a quick solution.
http://weblogs.thinktecture.com/cweyer/2012/11/oauth2-in-thinktecture-identityserver-v2-implicit-grant-flow-with-javascript.html
Thanks
Pablo.
I would like to have server side event in a full HTML5 application.
Server side I've an asp.net MVC3 web server, which gives HTML pages and JSON results.
What is the best way to integrate some server event? Like a process which can send some text message to client?
I've made some search and found something about a Asp.Net web api, but I don't know what it is and if I can use it with MVC.
You should have a look at http://signalr.net/ library. This blog post is also very informative.
SignalR looks very interesting, but maybe more than you really need. I've often wondered why people don't use Server-Sent Events more often, I haven't had the chance, but it looks like the simplest way of implementing.
Here is an example in MVC if you want to review: http://blogs.microsoft.co.il/blogs/gilf/archive/2012/04/10/using-html5-server-sent-events-with-json-and-asp-net-mvc.aspx
For those with experience, I'm looking to build some web services with Rails. These services will not served HTML content to a web browser and work strictly with XML and JSON only. Since Devise is a full blown MVC module, does it make sense for me? I need solid authentication with custom routes and access to Facebook Connect (OmniAuth looks good for this). I just don't need all of the additional work it's doing in views/layouts.
Is it still a good idea to try it out?
Yes, devise is worth it because it also handles all of the authentication you still need. The view-helpers are just one (very small) part of that functionality.
I'm a bit confused about all this OAuth bruhaha in the sense that all the examples I can find are for web applications and none of them for desktop applications.
I understand the Web application work flow, but that includes some redirections between the web app and twitter.
How does one do this in an desktop application?
How does the redirects work?
Should I have to include a Web Browser object?
Is there a way to go around this?
Could anyone point me to resources instead of a full blown solution please?
Thanks
Not sure which language you're using, but the .NET library for Twitter called Tweetsharp has a post on using Tweetsharp from a desktop app and authenticating via OAuth. See http://tweetsharp.com/?p=68. If you're not using .NET then perhaps it will inspire something you can do?
Basically, what tweetsharp does is launch the browser to the authentication URL and then waits for the user to return. I don't know of any way to do this other than something like that (Or include a WebBrowser control of some kind to launch the authentication URL in your own window).
Here's a straightforward solution, implemented as a set of PHP scripts for running from the command line. Well documented and explained, with a helpful 'verbose' option for debugging.
http://nullinfo.wordpress.com/oauth-twitter/
After some poking around and asking some questions about this subject to some other programmers, it looks like it's still an ongoing discussion, with no visible light at the end of the tunnel.
But for people interested on the ongoing discussion, here's the best link to have:
OAuth Desktop Discussion
I've seen a few desktop apps get around this by effectively embedding a browser into their program, so they can just open the in-app browser window to let you do the login and authorisation. This strikes me as a bit of a cheat or defeat of purpose because you still end up typing your ID and password inside the application anyway.
One possibility I was thinking of was, your desktop application could embed a mini HTTP server inside it. So then it launches the default browser to perform the authorisation, with a callback URL something like http://127.0.0.1:8765/oauthorized and then just listen for it.
Would that work?
Not sure what you would do for console applications... spawn a copy of lynx?
Include a WebBrowser control in your app. Put it in a panel or a separate form that you'll Form.ShowDialog().
Create a callback for the browser's successful posting of OAuth and one for a rejection. Don't forget to check for a FailWhale.
In the callback, you close the panel or form and store the token.
Here's a nice overview with sample code and everything: http://tweetsharp.com/2009/04/how-to-authenticate-a-desktop-application-with-oauth/