I built a web app in Laravel 5.2, and now, I would like to use Angular or Vue, so I am separating an API from my controllers.
Thing is actually, in my controllers, I use a lot :
Auth::user() to refer to the logged user.
What is the best way to deal with it???
Read books about API design. If the existing app isn't designed to be a RESTful API in the first place then you're in for a lot of learning. Laracasts has a great series called Incremental APIs.
Laracasts.com
Build APIs You Won't Hate
OK, I'm expanding my answer, despite this is not a great question, it is probably too broad. You need to look into Oauth 2.0 authentication for your API, you can still use a username and password, but OAuth 2.0 tokens over SSL is probably the best simple way to provide authentication for your API. If it is only used internally, or is read only then you may not really require authentication for the API at all. There's not enough information about your use case to even make a guess about that. Good luck!
Related
I am trying to develop a simple event-driven Slack bot that uses a user and a bot token to perform some authenticated API calls to Slack's Web API. The bot is functional, except I can't figure out how to use Bolt to store and manage the OAuth tokens after installation. This is my first time using OAuth, so apologies if I am missing anything obvious.
The best guidance I have found on using it is from this link: https://slack.dev/bolt-python/concepts#authenticating-oauth
However, I do not fully understand what an installation_store or state_store is, and more importantly, I am not sure how to access the stored tokens as needed. Furthermore, it seems like this solution relies on local persistence, but Heroku (where I deployed the bot) does not support that. I would prefer a cloud-based solution.
As a result, I decided to build a simple Flask app that handles the installation flow, making the authentication API call and storing the token(s) in a corresponding DynamoDB table. The tokens are stored as key-value pairs, with the key being either the team_id or the user_id, but I don't believe this works if one user uses the bot in multiple workspaces.
Furthermore, I feel like this solution is hacky and unmaintainble. What is the best way to handle the OAuth flow?
I stumbled on this question while trying to figure out the same myself. I can see that slack_sdk does support other installation and state stores like sqllite, aws,... unsure why the same was not carried forward in bolt for python. Having this feature of other stores would be better for security.
So I might suggest using slack_sdk instead of slack_bolt for now?
I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.
I want to make a list of goals for my family and I that we are all going to follow.
I generally know how I'll implement the list part. Just a todo-list-esque app where you only cross or uncross things off on it. I haven't decided with what I'll implement that part, mostly because I'm not sure how the multi-user part will go.
I figured each person can log in with Facebook or Twitter, and based on your login you'd be able to see what you've checked off.
I've never built a login before, or built based off of a logged in user.
Which web frameworks would be best for this? How would you implement this?
Since you said you know Javascript well, it sounds like you're best bet is to just use Node.js and a simple web framework like Express.js.
This will allow you to write you server-side code in Javascript, which should make the process simpler for you.
For handling authentication / etc., if you're looking for a stupid-simple authentication library you can use express-stormpath -- it supports social login as well as username/password stuff.
If you're looking for a smaller solution, you can use something like passport.js and use the third-party plugins for social login.
I have a web app implemented in Ruby on Rails 4, need an Android native app for it, I am really new to mobile development.
I am a bit confused as to what the mobile-web architecture should look like in this case. I've done some research online, there seems to be a few ways of doing this, but I still have some questions that I haven't been able to find answers for. Thanks in advance for all pointers.
1) do I really need a separate API for the mobile app? what are the issues in using my Rails app's existing controllers with respond_to format.json?
2) I've seen some online examples that suggest using an separate API namespace in the Rails app to serve mobile requests, e.g class Api::ApiController < ActionController::Base for the new controller, then add namespace :api do in routes.rb. With this approach, doesn't it imply that I'll need to duplicate quite a bit of my controller functionality in this new namespace just for mobile?
3) Regarding authentication, many examples suggest using token authentication, is the built-in Rails sessions management framework not good enough for mobile apps? or is it because session cookies work completely differently in a mobile app?
Appreciate your time.
It is not necessary, but it is, like you said, considered a best practice.
1+2) Having same controllers with respond_to/respond_with logic is a nice idea at first sight. But, from my experience, I can say, there always comes a day where API code start to differ with HTML client code. The mobile client might have a different UI and it is just natural that it will expect to consume your data another way as your web client does. The web client is specialized to one use case where an API should be more generic allowing multiple consuming ways.
The second issue that will arise is the fact that you cannot rely on your mobile users to always have the latest app version where with a webapp you can. So for the HTML app you can easily introduce non-compatible changes because you are delivering a proper client right within where for the mobile API breaking the API is at least concerning. Perhaps, you will want to maintain a backwards compatibility which will make your all purpose controllers ugly as hell. And without a proper api/v1 namespace you even can't have two different API versions at the same time.
You can avoid duplication of your logic by keeping your controllers very skinny and move the logic out into models (Service Objects are models too, not only Active Records).
3) Your mobile HTTP lib will to a high probability have a proper automatic cookie management. Having token based authentication is just again a best practice. If it is just a token vs session_id within cookie, there will be not much win. I can only think that it will be automatically secure against CSRF attack and you can disable this protection entirely for the API because your website users won't be allowed to consume the API, just by logging in to the site (an additional benefit perhaps). With session based authentication you will have to generate a CSRF token on first API request and set it within X-CSRF-Token cookie.
The big advantage of token based authentication is that it is extendable to more security, like introducing expire tokens, HMAC tokens etc, whereby session authentication is not.
See Using Sessions vs Tokens for API authentication
I would also encourage you to look at json:api. It comes from the creators of ember.js, who have thought about minifying decisions to take, when building APIs. Another interesting thing is an active_model_serializers gem. An intro to it is given within Rails: The Next Five Years by Yehuda Katz
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.