I was fiddling with sails.js and passport. Seems they are mend to be used together.
I have made the user models available in de db. And I am able to use the authentication by bcryptjs. This works, but dearly want to like to automatically authenticate every call, and mostly socket.io blueprint calls.
Still, I am searching for an elegant method to enable the sails.js way of integrating passport.
There are many examples, but seem a bit out-dated, not sure.
Important is the sockets. They need to be authenticated.
For e.g. every io.socket CRUD method, would be nice.
Kind regards
I found a link (http://www.bearfruit.org/2014/07/21/tutorial-easy-authentication-for-sails-js-apps/) that's pointing me in the right direction, but still not clear how this is reflected in for instance controllers
What I am trying to manage, is to have the custom api calls authenticated before they are called (configured in routes.js or by means of blueprints).
e.g:
OrderController:
module.exports = {
placeOrder: function (req, res) {
if (true === req.isSocket) {
// Pseudo code:
if (passport.authenticated(['user','admin'])) {
Order.save();
}
// end pseudo code
}
}
}
How should/is the above method secured, and I am I able to use for instance user-roles here?
I know two good solution for you question:
sails-auth
sails-generate-auth
Both implements passport, I recommend the first one, because it creates a layer to handle all authentication difficulties in model and services
Related
I've been using your advice and View::sharing all of my important data to all views. However, there is one issue I have encountered.
This code:
if(!Auth::guest()){
$user=Auth::user()->id;
}
else $user=0;
$temp=DB::select('query');
View::share('cartnumber', count($temp));
View::share('cartitems', $temp);
doesn't work when put in AppServiceProvider. Or better, it always sets $user=0, even if I am logged in. I thought it is because AppServiceProvider's boot function executes before the site checks if someone is logged in.
I then tried to use a BaseController with a construct function but that doesn't work either. The only solution that seems to work correctly is putting the code in every single Controller for every view! That actually works, which kind of confirms my theory.
But is there anywhere I can put this code without having to copy/paste it in every single Controller? Thanks in advance!
You'd likely want to put this code later in the request life cycle to guarantee an auth user because as others have mentioned middleware/session code has not occured during this part of the framework booting up. You could use a service class to call in all your controllers to avoid the copy pasting. Or If you'd like to achieve this using code in your service provider you could use a View Composer instead of a share this allows you to define a callback/or class that will be called right before the view is returned
view()->composer(['/uri-that-needs-data'], function ($view) {
if (Auth::check()) {
$cart = DB::query(...)->get();
$view->with('cartitems', $cart);
}
});
Check out https://laravel.com/docs/5.7/views#view-composers for more details.
Auth::user() will be empty until the session middleware has run.
The reason you can't access the user inside your service provider is because that code is run during the "bootstrapping" phase of the application lifecycle, when it's doing things like loading filesystem or cache drivers, long before the request is sent through response handlers (including middleware).
Once the application has been bootstrapped and all service providers
have been registered, the Request will be handed off to the router
for dispatching. The router will dispatch the request to a route or
controller, as well as run any route specific middleware.
Source: https://laravel.com/docs/5.7/lifecycle
If you don't want to copy/paste that code everywhere, then one place to put it is in custom route middleware. You can list it after the auth middleware to guarantee a logged-in user.
Edit: View composers are another really good option, as suggested by #surgiie. The reason these can be set up inside a service provider (unlike your example) is because the view composer registers a callback, but doesn't execute it until a much later stage in the application lifecycle.
Context to this post is I'm a java developer attempting to teach myself Ember. It isn't going well. I realize this question is pretty vague so I apologize, I'm not even sure what I should be asking...
I need to pull data into a model, i.e. via some sort of query, from a heroku json endpoint. In the application.js file, I have the following:
import DS from ‘ember-data’;
export default DS.JSONAPIAdapter.extend({
host: 'https://cag-brain.herokuapp.com'
});
Ideally I would like to pull this data into a user model, then display that data on a page as a sort of proof of concept. This unfortunately gets me nothing. Nor am I even sure I'm going about this correctly. Should I be doing something different than attempting to use Host Customization? Any guidance would be much appreciated!
There are different things involved for retrieving records via ember-data.
First of all you should define your models:
// app/models/post.js
import DS from 'ember-data';
export default DS.Model.extend({
title: DS.attr('string')
});
You should retrieve records in a model hook of a route.
// app\routes\posts.js
import Route from '#ember/routing/route';
export default Route.extend({
model() {
return this.get('store').findAll('post');
}
});
Then you should configure your api host and maybe a namespace. You included that step in your question:
// app/adapters/application.js
import DS from ‘ember-data’;
export default DS.JSONAPIAdapter.extend({
host: 'https://cag-brain.herokuapp.com'
});
If your api does not implement JSON Api specification you need to customize your serializer and adapter. Ember-data ships with a RESTAdapter/RestSerializer additionally to the default adapter and serializer which implements JSON Api spec. There is also one abstract adapter and serializer If you need to start from scratch. Before that I would definitely have a look if there is any community adapter/serializer fitting your needs.
To decouple api and client development and to speed up tests I would recommend ember-cli-mirage which allows you to mock your api.
I'm building an API in Laravel 5.4, using Laravel Passport 3 for authentication. All of my API methods return a set of values that are always returned, success, errors (if there are any errors) etc.
I've changed the response of a \Illuminate\Auth\AuthenticationException throws, to fit with the rest of my app, however I'm not sure how to change the response of various token grant responses, without doing something horrible like editing the vendor files.
I think you can use middleware to change your response.
From laravel documentation:
Before & After Middleware
Whether a middleware runs before or after a
request depends on the middleware itself.
You can capture the response and re-format the response.
You can use laravel's setContent method to set the content in response. Check here.
What you are trying to do here is not supported by the library, so whatever you do will be hacky and will probably break the compatibility with future versions of laravel/passport.
In my opinion, you can only choose between those 2 options:
Instead of declaring passport routes (Passport::routes()) you can declare equivalent routes to your custom methods. Those method internally calls Passport classes and methods, handling passport returning values before returning them to the user. It requires a lot of digging into passport code but, at the same time, if you only add some fields (success or error) you should be able to update your code without too much effort when updating the library.
Fork laravel/passport and modify it to suit you needs. This solution in not as messy as the first, but a merge with new versions of passport in the future will probably be hard.
Of course, both are not great solutions. Keeping the standard passport responses or use a more suitable library are better options: I assume they are not feasible if you are asking.
Another way - create proxy routes for your purposes.
Route::post('custom-auth/token', function (Request $request) {
$proxy = Request::create('oauth/token', 'POST', $request->request->input());
$response = app()->handle($proxy);
return responseCallback($response);
});
Where responseCallback your custom response modificator function.
My current setup is AngularJS + Django 1.5 and I have completely thrown away the use of Django's template engine (ie. the backend is pretty much an API server).
Since I am not using the csrf_token template tag, Django, in turn, does not set and send the csrftoken cookie in response. As instructed by the official docs, the ensure_csrf_cookie() decorator should be used to force the decorated view to send the csrftoken cookie.
I have applied the ensure_csrf_cookie() decorator to the view, which serves the first GET request that my web client calls at bootstrapping. With that, my web client gets a hold of the CSRF token and henceforth is allowed to call unsafe methods (ex. POST) to the server.
The above setup works fine only if the CSRF token remains the same until the browsing session ends.
Question: Does Django's CSRF token get updated during the course of a browsing session? If 'yes', does that mean I would need to apply the ensure_csrf_cookie() decorator to all the views I have?
1) Does Django's CSRF token get updated during the course of a browsing session?
Looks like the CSRF token is unique per session, but it is based in my observations, I have no "official" source. With Angular.js I use the following code without problems:
angular.module('app', ...)
.config(function($httpProvider) {
var cookies = document.cookie.split(';');
var csrftoken = _.find(cookies, function(v) {
return v.trim().indexOf('csrftoken=') == 0;
});
if(csrftoken) {
$httpProvider.defaults.headers.common['X-CSRFToken'] = csrftoken.split('=')[1];
}
})
Since I serve the HTML from Django, by the time Angular bootstraps the cookie is already there.
2) If 'yes', does that mean I would need to apply the ensure_csrf_cookie() decorator to all the views I have?
You can try CORS instead if CSRF. Otto Yiu maintains the django-cors-headers package, which is known to work correctly with REST framework APIs.
Some (untested) ideas to apply ensure_csrf_cookie():
monkey-patch APIView
create a CSRFCookie mixin and add it to your views
apply ensure_csrf_cookie() to your base classes
Giving support to the #Paulo Scardine ideas of applying the ensure_csrf_cookie() (which I consider valid, and useful), I would like to add a new one possible solution to it, if you definitely have to ensure_csrf_cookie() in all your views. You could write a custom middleware, and implement the logic that is there inside the ensure_csrf_cookie. Something like this:
On your app.middleware.py:
from django.middleware.csrf import get_token
class EnsureCsrfCookie(object):
def process_request(self, request):
# Forces process_response to send the cookie
get_token(request)
and of courses on your settings file add the middleware to the MIDDLEWARE_CLASSES:
MIDDLEWARE_CLASSES = (
.,
.,
.,
'app.middleware.EnsureCsrfCookie',
.,
.,
.,
)
It is just one idea more to face this problem. I hope it can be useful for somebody in the future.
I use a method to add CORS handlers to my response that is called by a client using Breeze.
You can read more about how I got that working here: Controller not filtering data in Breeze query in DotNetNuke Module
However, I noticed that while $filter works, $expand and $select do not.
So my question is: How can I use return a HttpResponseMessage Type and still use Breeze (I need to do this for CORS).
To prove this, I downloaded and changed the Todos sample:
Original method (works)
http://example/api/todos/todos?$select=isdone
[HttpGet]
public IQueryable<TodoItem> Todos()
{
return _contextProvider.Context.Todos;
}
My method with CORS wrapper (does not expand or select)
http://example/api/todos/TodosCors?$select=isdone
[HttpGet]
[Queryable(AllowedQueryOptions = AllowedQueryOptions.All)]
public HttpResponseMessage TodosCors()
{
var response = Request.CreateResponse(HttpStatusCode.OK, (IQueryable<TodoItem>)_contextProvider.Context.Todos);
return ControllerUtilities.GetResponseWithCorsHeader(response);
}
public static HttpResponseMessage GetResponseWithCorsHeader(HttpResponseMessage response)
{
response.Headers.Add("Access-Control-Allow-Origin", "*");
return response;
}
I'm going to comment mainly on the CORS aspect of your question. The part about $expand and $select is addressed in the StackOverflow question to which you refer. In brief, [Queryable] is the Web API attribute which does not support $expand and $select. I think you want the [BreezeQueryable] attribute that does.
I can not say for sure but I do not believe the code you show is the proper way to implement CORS for the Web API. At least I've not seen it done this way.
There are two ways known to me; both involve adding message handlers.
The first is the way we did it in the Breeze Todo sample; the second is the with the Web API CORS support that is on the way.
The way we did it is simplistic but effective. We don't talk about it because we intend to defer to the the approved Web API way when it arrives (soon I hope).
In the Todo demo, look for App_Start/BreezeSimpleCorsHandler.cs. You can just copy it into your own App_Start folder with no changes except to the namespace.
Then your server has to call it. In the Todo sample we did so in the BreezeWebApiConfig.cs but you could put it in Global.asax or in anything that is part of the server boot logic.
// CORS enabled on this server
GlobalConfiguration.Configuration.MessageHandlers.Add(new BreezeSimpleCorsHandler());
As it happens, someone has tried Breeze with the forthcoming Web API CORS NuGet package ... and discovered a bug in Breeze. We have to work that through ... and we will. We really want that way to be THE way.
Until then, you can follow the Todo sample precedent.