Re: [Catalyst] Applying a global SQL filter on REST controller.
Hi Mallah,
typically with DBIx::Class you would have a Chained root action in your
controller which puts an already filtered DBIx::Class resultset on the
stash and have all other action chained off this one.
DBIC::API provides generate_rs [1] to enable you to do this.
On 2017-02-06 07:12, Rajesh Kumar Mallah wrote:
Ok it did work out and i am able achieve what i wanted.
I created the below subroutine in:
ControllerBase/REST.pm
sub list_munge_parameters {
my ( $self, $c ) = @_;
$c->log->debug(" * list_munge_parameters callled!");
$c->req->_set_search_parameters( { society_id =>
$c->user->society_id() } );
}
But is it ok to use "PROTECTED METHODS" ?
They might be renamed, go away etc. on a refactor, which is why they
aren't exposed and documented.
Regds
Mallah
Best regards, Alex
[1] https://metacpan.org/pod/Catalyst::Controller::DBIC::API#generate_rs
Ok i do see some light! that I am exploring.
Sorry for the noise i shall post again if i find a
solution or otherwise even.
http://search.cpan.org/~abraxxa/Catalyst-Controller-DBIC-API-2.006002/lib/Catalyst/Controller/DBIC/API.pm
list_munge_parameters
list_munge_parameters is a noop by default. All arguments will be passed
through without any manipulation. In order to successfully manipulate the
parameters before the search is performed, simply access
$c->req->search_parameters|search_attributes (ArrayRef and HashRef
respectively), which correspond directly to ->search($parameters,
$attributes). Parameter keys will be in already-aliased form. To store the
munged parameters call $c->req->_set_search_parameters($newparams) and
$c->req->_set_search_attributes($newattrs).
Dear Catalyst Experts/Users/Hackers,
Please guide for the below situation,
I have put reasonable effort by searching on online
resources.
We have an application backed by SQL tables that stores
data of multiple customers in same table . We have
many such tables and all of them bear a column customer_id
for separating the records of one customer to another.
The security isolation requirement is that one customer should
not get to see records of other customer. What i have in mind
is to append an SQL filter customer_id = << customer_id of logged in
customer >>
at a global level . The controller modules for each database table are
being (auto)generated by the helper
Catalyst::Helper::Controller::DBIC::API::REST The dataset is being
exposed
via REST utilising
Catalyst::Controller::DBIC::API
Can anyone please guide where such a constraint can be put ?
Regds
Rajesh Kumar Mallah.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Applying a global SQL filter on REST controller.
Ok it did work out and i am able achieve what i wanted.
I created the below subroutine in:
ControllerBase/REST.pm
sub list_munge_parameters {
my ( $self, $c ) = @_;
$c->log->debug(" * list_munge_parameters callled!");
$c->req->_set_search_parameters( { society_id =>
$c->user->society_id() } );
}
But is it ok to use "PROTECTED METHODS" ?
Regds
Mallah
>
>
> Ok i do see some light! that I am exploring.
> Sorry for the noise i shall post again if i find a
> solution or otherwise even.
>
>
>
http://search.cpan.org/~abraxxa/Catalyst-Controller-DBIC-API-2.006002/lib/Catalyst/Controller/DBIC/API.pm
>
> list_munge_parameters
>
> list_munge_parameters is a noop by default. All arguments will be passed
> through without any manipulation. In order to successfully manipulate the
> parameters before the search is performed, simply access
> $c->req->search_parameters|search_attributes (ArrayRef and HashRef
> respectively), which correspond directly to ->search($parameters,
> $attributes). Parameter keys will be in already-aliased form. To store the
> munged parameters call $c->req->_set_search_parameters($newparams) and
> $c->req->_set_search_attributes($newattrs).
>
>
>
>> Dear Catalyst Experts/Users/Hackers,
>>
>> Please guide for the below situation,
>> I have put reasonable effort by searching on online
>> resources.
>>
>>
>> We have an application backed by SQL tables that stores
>> data of multiple customers in same table . We have
>> many such tables and all of them bear a column customer_id
>> for separating the records of one customer to another.
>>
>>
>> The security isolation requirement is that one customer should
>> not get to see records of other customer. What i have in mind
>> is to append an SQL filter customer_id = << customer_id of logged in
>> customer >>
>> at a global level . The controller modules for each database table are
>> being (auto)generated by the helper
>> Catalyst::Helper::Controller::DBIC::API::REST The dataset is being
>> exposed
>> via REST utilising
>> Catalyst::Controller::DBIC::API
>>
>> Can anyone please guide where such a constraint can be put ?
>>
>> Regds
>> Rajesh Kumar Mallah.
>>
>>
>>
>>
>>
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
>
>
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Applying a global SQL filter on REST controller.
Ok i do see some light! that I am exploring. Sorry for the noise i shall post again if i find a solution or otherwise even. http://search.cpan.org/~abraxxa/Catalyst-Controller-DBIC-API-2.006002/lib/Catalyst/Controller/DBIC/API.pm list_munge_parameters list_munge_parameters is a noop by default. All arguments will be passed through without any manipulation. In order to successfully manipulate the parameters before the search is performed, simply access $c->req->search_parameters|search_attributes (ArrayRef and HashRef respectively), which correspond directly to ->search($parameters, $attributes). Parameter keys will be in already-aliased form. To store the munged parameters call $c->req->_set_search_parameters($newparams) and $c->req->_set_search_attributes($newattrs). > Dear Catalyst Experts/Users/Hackers, > > Please guide for the below situation, > I have put reasonable effort by searching on online > resources. > > > We have an application backed by SQL tables that stores > data of multiple customers in same table . We have > many such tables and all of them bear a column customer_id > for separating the records of one customer to another. > > > The security isolation requirement is that one customer should > not get to see records of other customer. What i have in mind > is to append an SQL filter customer_id = << customer_id of logged in > customer >> > at a global level . The controller modules for each database table are > being (auto)generated by the helper > Catalyst::Helper::Controller::DBIC::API::REST The dataset is being exposed > via REST utilising > Catalyst::Controller::DBIC::API > > Can anyone please guide where such a constraint can be put ? > > Regds > Rajesh Kumar Mallah. > > > > > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Applying a global SQL filter on REST controller.
Dear Catalyst Experts/Users/Hackers, Please guide for the below situation, I have put reasonable effort by searching on online resources. We have an application backed by SQL tables that stores data of multiple customers in same table . We have many such tables and all of them bear a column customer_id for separating the records of one customer to another. The security isolation requirement is that one customer should not get to see records of other customer. What i have in mind is to append an SQL filter customer_id = << customer_id of logged in customer >> at a global level . The controller modules for each database table are being (auto)generated by the helper Catalyst::Helper::Controller::DBIC::API::REST The dataset is being exposed via REST utilising Catalyst::Controller::DBIC::API Can anyone please guide where such a constraint can be put ? Regds Rajesh Kumar Mallah. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
