How do I add permissions to ActiveStorage? - rails-activestorage

I'm migrating to ActiveStorage an app that is permissions sensitive. I need to make sure files are only accessed by people with permissions, and that those permissions only last for a specified period of time.
With Paperclip, that was as easy as defining a route with a pundit authorization call:
def thumbnail
authorize #record
redirect_to #record.thumbnail.expiring_url(300)
end
Any call to /record/thumbnail would be authenticated by devise, authorized by pundit, and then redirected to S3 with an expiring url. It's a process that worked.
Moving to ActiveStorage, my initial thought was I'd use service_url, but it only works if I'm using S3 -- it doesn't work in testing, it doesn't work if I'm in local development with a disk service. The actual, 'correct' approach is to use url_for, or in the example above redirect_to url_for #record.thumbnail.
The problem is, url_for appears to issue a permanent url -- the url it generates is always valid, for anyone, without authentication or authorization. More importantly, once someone has that url, I can't revoke it, I can't say it's only good for a week. Once someone has that url, they have access to the file, forever. (Or, presumably, at least until the file is updated).
I don't think it's a huge security flaw, but it's definitely a step backward from what was achievable using Paperclip. Am I missing an important detail, or is this really all that's doable with ActiveStorage?

The documentation says:
If you need to enforce access protection beyond the security-through-obscurity factor of the signed blob references, you'll need to implement your own authenticated redirection controller.
Which is not particularly helpful. To do this you create your own controller to serve the blobs:
class BlobsController < ApplicationController
include ActiveStorage::SetBlob
before_action :authorize_blob
def show
expires_in ActiveStorage::Blob.service.url_expires_in
redirect_to #blob.service_url(disposition: params[:disposition])
end
private
def authorize_blob
# Your authorization code goes here
end
end
Then you will need to set up your routing:
get '/blobs/:signed_id/*filename' => "blobs#show", as: "service_blob"
direct :blob do |blob, options|
route_for(:service_blob, blob.signed_id, blob.filename, options)
end
resolve("ActiveStorage::Blob") { |blob, options| route_for(:blob, blob, options) }
Finally, you need to disable the insecure default controller so that a knowledgeable user cannot circumvent your authorization.
If you are in Rails 6.1+, you can do this by setting config.active_storage.draw_routes to false in your application.rb. But you will then need to make sure the rest of the ActiveStorage routes are drawn manually and there are quite a few of them. You can view them on Github.
Otherwise, you will need to add extend the controller to redirect to your new one (or just shut it down entirely). You can add the following to an initializer:
module ActiveStorageRedirect
def self.included(controller)
controller.before_action :redirect_to_authenticated
end
private
def redirect_to_authenticated
redirect_to Rails.application.routes.url_helpers.blob_path(#blob)
end
end
ActiveStorage::Blobs::RedirectController.include(ActiveStorageRedirect) # For Rails >= 6.1
ActiveStorage::Blobs::ProxyController.include(ActiveStorageRedirect) # For Rails >= 6.1
# ActiveStorage::BlobsController.include(ActiveStorageRedirect) # For Rails < 6.1

Related

Prevent showing the UI5 app internal page without successful authentication

OpenUI5 version: 1.86
Browser/version (+device/version): Chrome Dev
Upon the authentication I validate the user session:
if (isUserSessionValid) {
const oRouter = UIComponent.getRouterFor(this);
oRouter.navTo("overview");
} else {
this.getOwnerComponent().openAuthDialog();
}
If isUserSessionValid is true, then I forward an user to the internal page, otherwise I show the login dialog.
The problem is, however, that an user can change the value of isUserSessionValid in DevTools and then getting forwarded to the UI5 app internal page. Of course, due to a lack of a valid session, no piece of the business data will be displayed, just an empty UI5 app template, but I would like to prevent even such screen.
If it would be a classical webapp, I would just send an appropriate server response with a redirect to the login page (e.g. res.redirect(403, "/login");). But, if I understand it correctly, since I'm sending am asynchronous request, a plain res.redirect won't work out and I'm required to implement a redirection logic on the UI5-client, which can be manipulated and bypassed by user.
How to prevent a manipulation of a view navigation in UI5 and ensure that unauthorized user can't get any piece of the UI5-app code?
The answer from SAP:
If you want to prevent an unauthorized user from accessing the client-side code (e.g. view/controller) you need to enforce
authorization on the server also for those static files. When bundling
the application code you also need to ensure that those files are
separate from the "public" files. One approach would be to have 2
separate components, one for the public page/auth dialog and one for
the actual application.

How can I protect the loopback explorer by username and password?

I've just started using loopback4 and I would like to protect the /explorer from being public. The user would initially see a page where username and password must be entered. If successful, the user is redirected to /explorer where he can see all API methods (and execute them). If user is not authenticated, accessing the path /explorer would give a response of "Unauthorized". Is there a way to easily implement this?
There is issue talking about a GLOBAL default strategy is enabled for all routes including explorer in https://github.com/strongloop/loopback-next/issues/5758
The way is to specify a global metadata through the options:
this.configure(AuthenticationBindings.COMPONENT).to({
defaultMetadata: {
strategy: 'JWTStrategy'
}
})
this.component(AuthenticationComponent);
registerAuthenticationStrategy(this, JWTAuthenticationStrategy)
But in terms of enabling a single endpoint added by route.get(), it's not supported yet, see code of how explorer is registered. #loopback/authentication retrieves auth strategy name from a controller class or its members, but if the route is not defined in the controller, it can only fall back to the default options, see implementation

How to access "current logged-in user" in remote methods?

recently in one of my applications I needed to access currently logged-in user data for saving in another model (something like the author of a book or owner of a book). in my googling, I encountered these references but none of them was useful.
https://github.com/strongloop/loopback/issues/1495
https://docs.strongloop.com/display/public/LB/Using+current+context
...
all of them have this problem about accessing context or req object. after three days I decided to switch to afterRemote remote hook and add Owner or Author on that stage.
but something was wrong with this solution.
in strongloop's documentations (https://docs.strongloop.com/display/public/LB/Remote+hooks) there is a variable as ctx.req.accessToken that saves current logged-in user access token. but in the application this variable is undefined.
instead, I found accessToken in ctx.req.query.access_token and it was currently access_token variable that is sent to the server.
here is my problem:
is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
in production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
why ctx.req.accessToken is undefined?
could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
Is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
Well if your application always sends in the querystring, then it'll be always available for you, but it also sent in the header, or cookie or in the request body, but I don't suggest using it because it if the user logged in and the access token is valid and ctx.req.accessToken should be available and you can use it.
In production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
I believe Authorization header is preferred, as if you send it in a GET variable, well it'll be visible in the logs and someone with the access to the logs can access the session(well unless you trust everyone), other than this it's fine to have it in a GET variable. Though I believe loopback client SDKs(Angular, Android, iOS) all send it via Authorization header by default, so you might have to configure them(maybe not possible).
Why ctx.req.accessToken is undefined?
Sometimes the context is lost thanks to the database drivers connection pooling, or the context req is lost(ctx.req) and they are null.
Assuming ctx.req is defined(because sometimes it's not), then probably that means the user is not logged it, or it's access token wasn't valid(expired or not in database). Also it could be a bug(maybe misconfiguration on your side), which also means for you that you will authentication problems.
Could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
app.getCurrentContext is risky to use and I don't suggest unless you have no other solution. If you use it and it works, it might stop working if the database driver changes or in some corner cases that you haven't tested it, it might not work.
In the updated doc https://loopback.io/doc/en/lb3/Using-current-context.html
add this in your remoting metadata
"accepts": [
{"arg": "options", "type": "object", "http": "optionsFromRequest"}
]
then
MyModel.methodName = function(options) {
const token = options && options.accessToken;
const userId = token.userId
}
but it says
In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.
so add "injectOptionsFromRemoteContext": true on your model.json file

simple form symfony2 firewall redirection

Here is my issue.
Situation:
I am trying to add some custom logic during user login. I could find to ways to do so:
hard way (but with a lot of control); building my own authentication provider, following this guidelines of the cookbook or this complementing publication of vandenbrand
easy way (exactly what I need ): use simple_form. simple_form is a key which has the same options as form_login, but for which I can define an "authenticator".
cookbook tuto I used can be found here
Issue
I had an existing and operational app/security.yml configuration with 'form_login' key.
secured_area:
pattern: ^/foo/user/secured/
form_login:
check_path: /foo/user/secured/login_check
login_path: /foo/user/login
I followed steps of the tutorial described above. therefore, my security.yml gets modified to:
secured_area:
pattern: ^/foo/user/secured/
#form_login:
simple_form:
authenticator: foo_authenticator
check_path: /foo/user/secured/login_check
login_path: /foo/user/login
when I try to access a page /foo/user/secured/target of the secured area, the firewall does its job: it catches the query and asks for credentials (via intermediary page /foo/user/login).
However, once right credentials input (and obviously validated), I keep staying on the same page. It does not redirect to the page /foo/user/secured/target I was asking for in the first place. There is no refreshing to trying to go to that page via new request: I remain stuck at login stage.
EDIT 1: here are the steps I identify based on logs and debugging:
1) user tries to access /foo/user/secured/target, for which you need to be identified at least with ROLE_USER to access
2) firewall intercepts this request, as it matches listened routes (app/config/security.yml):
secured_area:
pattern: ^/foo/user/secured/
3) it redirects toward login route
4) user fills in with username and password, and submits post
5) when form is received, a token gets created by createToken method of custom authenticater. It returns an object of class UsernamePasswordToken created with parameter username, password in clear, authenticater key: UsernamePasswordToken($username, $password, $providerKey)
6) token gets passed onto authenticateToken method de of authenticater object. this method compares clear password hash contained in token andd accessed through $token->getCredentials()) with hashed password in database.
7) authentication worked: we get redirected toward /foo/user/secured/target . token and user get serialized in session (ISSUE STARTS HERE: indeed, user clear password is erased so that it doesn't leave tracks in session, and getCredentials() will return empty string now).
8) while loading page, le firewall is activated. It detects user logged in, seems to want to check its token. Therefore, it calls authenticateToken.
9) authenticateToken tries to compare sha1($token->getCredentials()) to hashed password in database. comme $token->getCredentials() is empty, comparison fails. authenticateToken raises an exception.
10) raised exception triggers firewall redirection toward login page. There we are: stuck in infinite loop landing systematically on login page.
STOP EDIT 1.
Solution
Does anyone know why this change of behaviour between 'form_login' and 'simple_form'? Most of all, would you know a good way to fix this ? I guess authenticate method or custom authenticater should be slightly changed, but I am not yet confident enough with security to solve this elegantly.
Many thanks in advance.
Kind regards,
Wisebes
You have to use some string (not the object) from sample. Or implement __toString() for User entity.
NOT
return new UsernamePasswordToken($user, ...
USE
return new UsernamePasswordToken($user->getEmail() or whatever, ...
if you want to access to the page you was requesting, you could use any of the options that Symfony offers to you:
Redirecting after Login:
always_use_default_target_path (type: Boolean, default: false)
default_target_path (type: string, default: /)
target_path_parameter (type: string, default: _target_path)
use_referer (type: Boolean, default: false)
You could see the section of the book 'SecurityBundle Configuration ("security")'
http://symfony.com/doc/current/reference/configuration/security.html
I hope that this be useful for you.
Kind regards.
well, as I was not able to make it work fine, I created my own custom authentication provider. I hope the issue reported above will be fixed asap. If anyone has got an answer, I still am interested!
For other people facing the same issue, I recommend creating a custom authentication provider. You may even inherit from existing authentication provider, and therefore limit modifications to be done. All in all, you are able to add your custom logic with a limited amount of trouble that way.

Occasionally disabling Pyramid middleware

Note: If it's any help, I'm using Pyramid 1.3.2. I know it's a little out of date, I would prefer not to update right away, but I might be able to force an update if the latest version provides better support for this use case.
The Pyramid-based application I'm working on has a strict authorization policy: all calls must be authenticated. Since 1) it's tedious to add this manually on every request handelr; and 2) we don't want anybody to "forget" adding authentication, we enforce this server-wide using a simple Pyramid middleware (tween) that verifies all incoming requests.
Recently, this restriction has been slightly relaxed: occasionally, some resources should support (safe & idempotent) GET without authentication.
It seems this is directly opposed to the usual design ideas behind authentication in most web frameworks (optional authentication), so I can't get it to work quite as expected.
QUESTION: What is the correct approach to implementing an authorization middleware that authenticates & verifies authorization by default, but can be disabled on a view-by-view basis?
So far, I've tried adding a simple decorator like so:
def allows_anonymous_access(f):
f.allows_anonymous_access = True; return f
#allows_anonymous_access
def my_pyramid_view(request):
# ...
In my middleware, I would like to use it like this:
def authorization_middleware(handler, registry):
def verify_authorization(request):
# Identify the user making the request. Make sure we get the
# user's identify if provided, even when the request handler
# allows anonymous access.
try:
request.principal = extract_user(request)
except InvalidCredentials, error:
if getattr(handler, 'allows_anonymous_access', False):
request.principal = AnonymousUser()
else:
raise HTTPUnauthorized(...)
# Invoke the handler.
return handler(request)
# Middleware that will pre/post-process the request.
return authorization_middleware
However, when the middleware executes, handler is not my view. It happens to be a bound method (pyramid.router.Router.handle_request) which does not provide me access to the view callable, meaning I cannot access the flag set by the middleware.
You probably want pyramid.config.set_default_permission(permission). From docs:
Adding a default permission makes it unnecessary to protect each view
configuration with an explicit permission, unless your application
policy requires some exception for a particular view.
If a default permission is in effect, view configurations meant to
create a truly anonymously accessible view (even exception view views)
must use the value of the permission importable as
pyramid.security.NO_PERMISSION_REQUIRED. When this string is used as
the permission for a view configuration, the default permission is
ignored, and the view is registered, making it available to all
callers regardless of their credentials.
Answer provided by raydeo_ on #pyramid freenode IRC channel.

Resources