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/