it took some digging but I think I got it. Message Headers are part of the sub classes. MSMQ current message subtype is public while RQ current message subtype is internal. Here are the steps i took to get this working: In RSB 1. make RhinoQueueCurrentMessageInformation public. 2. mark RhinoQueueCurrentMessageInformation with the attribute CLSCompliant(false) 3. compile in my project 4. cast CurrentMessageInformation to RhinoQueueCurrentMessageInformation. 5. added credentials to header
Are there are ramifications to marking RhinoQueueCurrentMessageInformation with the CLSCompliant(false) attribute? I briefly looked into making CurrentMessageInformation abstract with a header implementation, but this caused a more compiling issues than I anticipated. it would also require another subclass since CurrentMessageInformation is directly instantiated for a number of operations. I wasn't sure if this would impact Esent tables schema's either with RQ. On Mar 26, 3:05 pm, Ayende Rahien <[email protected]> wrote: > Yep, pretty much the same thing can be done with RSB. > The message headers are available for the message module. > > On Thu, Mar 25, 2010 at 2:25 AM, Udi Dahan <[email protected] > > > wrote: > > In NServiceBus we pass the user credentials in the headers of the message > > and use them on the receiving end to set the principal of the running > > thread. I imagine that something similar would be possible with RSB. > > > -- Udi Dahan > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Jason Meckley > > Sent: Wednesday, March 24, 2010 11:01 PM > > To: Rhino Tools Dev > > Subject: [rhino-tools-dev] authorizing messages/consumers > > > I would like to authorize a message can be executed before consuming. > > my first approach was to add a UserId property. the back end would > > pull the user id from the message and authorize the user can infact > > execute the message. > > > This made sense in the beginning, but now I'm looking at my messages > > and thinking. "UserId doesn't belong there". 2 ideas of how to remedy > > this came to mind. > > > #1 tack the userid on to the uri. from the client add a message module > > to append the userid as a query string to the destination uri. on the > > backend have a message module to pull the userid out of the source uri > > and authorize the message when it arrives. > > > #2. authorize commands on the client before sending. no need to alter > > any part of the service bus infact authorization would happen at the > > controller action. using a bus becomes irrelevant on the client. at > > the destination validate the message came from a valid source (in this > > case the website). if it came from somewhere else it, fail. > > > #2 seems simpler. #1 seems like it would only be applicable in some > > extreme security context. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Rhino Tools Dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rhino-tools-dev%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Rhino Tools Dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rhino-tools-dev%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
