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.
Related
I created a Rails API application, that is currently do his job awesomely, but I realized that is missing the most important part, a login from the React application and at the same time the authentication from a python application I developed that should consume those API as well.
Now, looking at the various offering, seems all fuzzy, at least from my prospective and I would like to have an advice that is not from 2016 or before but that is actual today.
Many solutions on the net, was getting dirty the main ApplicationController, that didn't make sense to me.
So I thought that a 'modern' way or let's say, 'a way' is to use doorkeep and devise.
I thought about Doorkeep because allow me to have the 'Applications' therefore I can delegate to applications the authentication in the proper way while using the JWT for the SPA application, but honestly I don't know from where to start deciding :)
I wanted to share here also the link of a blog post that inspired this question: https://www.vic-l.com/jwt-with-refresh-token-using-devise-and-doorkeeper-without-authorization/
Sadly something I found still, without an answer, at the moment, is Setting up DoorKeeper with multiple Rails/React applications?
Now, I can use doorkeeper to manage the JWT for the SPA and the applications for the client in Python ?
Thanks in advance!
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 am reading the Service Oriented Design with Ruby book by Paul Dix and many posts here but am left with many questions surrounding authenticating users and the application.
I want to have api.site.com as a RESTful Rails app serving up JSON. Secure.site.com will be a web app (maybe Rails or maybe PHP) that will consume the service. Also a mobile app such as iPad will also consume it.
So is the first step to build in a level of auth so that only my web app and mobile app can consume the service? Then once the calling app has been authenticated, both these apps will have users who want to CRUD their data so then authenticate them as well?
I've read about Http basic, digest, tokens, oauth and many plugins but am having a difficult time narrowing down the most flexible and reusable way. For now this is simply learning so I would like to stay away from plugins so I can learn the code better.
Can my web app use normal sessions like I'm familiar with and then the mobile use their equivalent to sessions. At that point I still have no authenticated the calling app though. Http basic seemed like I could use it from both, but I didn't see a way for my web app to use a normal login form and logging out seemed like an issue.
I would suggest two solutions for you.
Use a Gem like devise for login system and inherit the devise registration and sessions controller to make it respond to JSON requests.
Create your own simple authentication and use respond to HTML and respond to JSON for separating web and mobile login
Iam not totally sure whether a mobile device maintains a session (please look around) but u can always use a token authentication system if it doesnt.
I've seen several similar scenarios explained here but not my particular one. I wonder if someone could tell me which direction to go in?
I am developing two (and more later) MVC2 apps. There will also be another (thicker) client later on (WPF or Silverlight, TBD).
These all need to share the same authentication. For the MVC2 apps they (preferably) need to be single log on - ie if a user logs in to one MVC2 app, they should be authorised on the other, as long as the cookie hasn't timed out.
Forms authentication is to be used.
All the apps need to use common business functionality and perform db access via a common WCF Service App. It would be nice (I think) if the WCF is not publicly accessible (ie blocked behind FW). The thicker client could use an additional service layer to access the Common WCF App.
What this should look like is:
MVCApp1 -> WCFAppCommon
MVCApp2 -> WCFAppCommon
ThickClient -> WCFApp2 -> WCFAppCommon
Is it possible to carry out all the authentication/authorization in the WCFAppCommon?
Otherwise I think I'll have to repeat all the security logic in the MVCApps and WCFApp2, whereas, to me, it seems to sit naturally in WCFAppCommon. On the otherhand, it seems if I authenticate/authorize in WCFAppCommon, I wouldn't be able to use Forms Authentication.
Where I've seen possible solutions (that I haven't tried yet) they seem much more complex than Forms Authentication and a single DB.
Any help appreciated,
Phil
I thought I should come back to this with what I've learned (and re-learned).
First the re-learned lesson - don't become fixed on an architecture and then try and make everything else fit. I'm fixed on .Net, SQL Server, WCF, MVC2, EF4, and IIS7. Fixing in my mind how I want these to fit together is slighly dumb! Better to go out and look at what guidance exists.
Which brings me to what I learned - here's a link:
http://wcfsecurityguide.codeplex.com/
I discounted this article a couple of times because it's a bit dated. However, I'd say it's actually very relevant and if you're starting a project remotely concerned with securing services go take a look. Part IV had everything I needed.
We are using WCF Web Application hosting Reporting system (we are accessing it from Silverlight) and since it's using same machine keys as our MVC application - we can share cookie authentication as well.
Otherwise, you have to send authentication ticket (custom or not) to your WCF application.
Our shop is in the process of converting our internal project management application from ASP.NET Web Forms to ASP.NET MVC.
I would like to provide an RSS feed for our customers of their current open issues ... but I would like to do so with some type of authorization, e.g. login and a password.
Is this possible using ASP.NET MVC or should this be done through some other service like WCF? Sample code would be much appreciated.
I'm not sure of the best way, but can think of a few, none are super great though.
Use IIS WindowsAuthentication with basic security and implement the validation method and then mark the RSS action with an authorize filter. If they are using an RSS feeder that doesn't allow http authentication, you should still be able to do http://username:password#mysite.com/controller/action/rss.
Generate a token for each customer and place it in part of the url: http://mysite.com/controller/action/rss/{token}. This isn't that great.
Put the username/password as part of the route: http://mysite.com/controller/action/rss/{username}/{password} ... this is pretty horrible though.
All of them kinda suck because the password (or token) is url visible. Maybe that is considered okay if it is https instead of http though. I think the first option + https is pretty common though?
If private feeds are part of the RSS spec, you should look there for the mechanics of RSS auth.
I've thought about this before for a project and came to the conclusion that secure RSS will never work because not enough clients (e.g. google reader) support it.
Sorry, don't have a complete answer, but thought this might help anyway.