Hi Darshana,
> Hi Hasanthi, > > On Tue, Jan 23, 2018 at 10:54 PM, Hasanthi Purnima Dissanayake < > [email protected]> wrote: > >> Hi All, >> >> Requirement : >> We have a requirement to insert/update or delete a row from a db table >> once access token or authorization code is generated, revoked, code or >> token status changed or a refresh token is issued. Without directly >> invoking the db, we thought of implementing events to trigger when one of >> the above scenario happens. >> > > Can you explain the need of a event mechanism for these use cases.. What > are the problems that we try to overcome using the new method? > The actual flow is as below. In OIDC RO(Request Object) implementation we persist RO against the Session Data Key and we update the row of RO table once the code or a token is generated. And once the token/code is revoked/state changed we need to delete the row accordingly. So we need to insert/update/delete rows to the RO table based on the inserts revokes and deletions of the relevent tables. Actually I don't see a huge advantage by engaging event mechanism here. When introducing new APIS or features which effects to tokens or codes flow in future, then we ned to put the same logic to update RO table everywhere if we don't use events. So it will be clean if we can engage the event mechanism here. Thanks, On Tue, Jan 23, 2018 at 11:17 PM, Darshana Gunawardana <[email protected]> wrote: > Hi Hasanthi, > > On Tue, Jan 23, 2018 at 10:54 PM, Hasanthi Purnima Dissanayake < > [email protected]> wrote: > >> Hi All, >> >> Requirement : >> We have a requirement to insert/update or delete a row from a db table >> once access token or authorization code is generated, revoked, code or >> token status changed or a refresh token is issued. Without directly >> invoking the db, we thought of implementing events to trigger when one of >> the above scenario happens. >> > > Can you explain the need of a event mechanism for these use cases.. What > are the problems that we try to overcome using the new method? > > Thanks, > > >> So the existing architecture is kind of service layer is responsible of >> issuing/revoking/deleting tokens or codes and this layer is directly >> invoking the DAO layer for db calls. So we have two places to implement >> events in the service layer or the DAO layer. >> >> Problem : >> If we are implementing the events in the service layer, then we have to >> trigger multiple events in multiple places as we are doing above operations >> in multiple places in the service layer. Also some of the service layer >> classes are extensible so we cannot guarantee that a third party extension >> developer will implement the events in the extended code. >> >> If we are implementing the events in the DAO layer, then the DAO layer >> isolation will be violated. >> >> Ideally there should be a middle layer in between the service layer and >> the DAO layer for such kind of situations. As we don't have such a middle >> layer, ATM we have implemented the events in the DAO layer. >> >> Highly appreciate any feedback on above. >> >> Thanks, >> >> -- >> >> Hasanthi Dissanayake >> >> Senior Software Engineer | WSO2 >> >> E: [email protected] >> M :0718407133| http://wso2.com <http://wso2.com/> >> > > > > -- > Regards, > > > *Darshana Gunawardana*Technical Lead > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . > Middleware > -- Hasanthi Dissanayake Senior Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
