You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Matterhorn needs a request_env to store it's request logic. Currently there isn't good separation of concerns between the logic for generating the links inclusions and the actual display of those objects.
This is needed prior to finishing the code for inclusions, which currently don't track the request env at all. Inclusions will need to have access to request_env in order to check for authentication visibility... e.g. if you request an inclusion that requires authentication, the inclusion will need to decide how to handle that (raise a 403, ignore request).
This would include:
the current_user for the request
the primary resource/collection
link objects available to the request.
inclusions requested.
In your api app, most code bases should setup the following code:
# app/controllers/application_controller.rbclassApplicationController < Matterhorn::BaseincludeAuthenticationCode# this is custom to you're apphelper_method:current_useradd_env:current_userprotected###################################defcurrent_user@current_user ||= beginUser.where(id: session[:user_id]).firstendendend
Now within requests:
# app/controllers/posts_controller.rb# matterhorn index methods should handle the index # methods for you, this is just to demonstrate that the# request_env is available as an instance method.defindexrequest_env[:current_user]# == current_userend
When the request_env is called it should load each of the methods into a memoized hash. If it is not called, current_user shouldn't be built.
# builder_supportdefbuild_json# this should merge controller.request_env into the base object, to be mixed into options for scoped collection/resource.end
The text was updated successfully, but these errors were encountered:
Matterhorn needs a request_env to store it's request logic. Currently there isn't good separation of concerns between the logic for generating the links inclusions and the actual display of those objects.
This is needed prior to finishing the code for inclusions, which currently don't track the request env at all. Inclusions will need to have access to request_env in order to check for authentication visibility... e.g. if you request an inclusion that requires authentication, the inclusion will need to decide how to handle that (raise a 403, ignore request).
This would include:
In your api app, most code bases should setup the following code:
Now within requests:
When the
request_env
is called it should load each of the methods into a memoized hash. If it is not called, current_user shouldn't be built.The text was updated successfully, but these errors were encountered: