Yeah - security by obscurity didn't fly too well with the security guys :)
On Sat, Mar 14, 2009 at 9:07 AM, Ayende Rahien <[email protected]> wrote: > use a guid as the rest key, you can be assured that it will not be > guessable. > however, at the point, you have to worry about traffic sniffing, etc > in general, you don't want caching of sensitive info > > On Sat, Mar 14, 2009 at 6:00 PM, Matt Burton <[email protected]> wrote: >> >> Yep - that's where we are at now, like I said this was an early spike. >> We're now using the typical Amazon "we got your request and we're >> working on it" for commands sent into the system, and then a thin WCF >> web service layer for doing reads/queries that just read straight from >> the data store with authorization (interceptor/behavior) to make sure >> the user can read that data. Here there are polling operations exposed >> that can be used by the client for things like AJAX spinner scenarios. >> >> I'd like to move the query part to REST, but the downside is the data >> is of a sensitive nature, so we'd have to use HTTPS or use HTTP and >> encrypt the document on the server and decrypt on the client in >> JavaScript (suggested by Udi in a comment on one of his blog >> posts...don't know how I feel about that though...) so we're >> effectively bypassing the potential benefits of REST. HTTPS internet >> traffic won't be cached (some proxies can, I know, but not all will) >> and browsers will most likely not cache it locally, and the client >> decrypt in JavaScript doesn't sound like the ideal solution either... >> Oh, and as for caching on the server, we are doing this for smaller >> datasets, but when you're talking about the "give me page N of 100 >> pages of data" scenario caching everything and using pub-sub to >> maintain the cache starts to break down. So our current take is to >> have a set of query capabilities that's hitting either denormalized, >> preprepared data (maintained via pub-sub) or finely tuned access paths >> to the normalized data. Not perfect, but works for now... >> >> On Fri, Mar 13, 2009 at 6:13 PM, Ayende Rahien <[email protected]> wrote: >> > I would _strongly_ recommend moving to a polling option instead of >> > locking, >> > >> > On Sat, Mar 14, 2009 at 6:12 AM, Matt Burton <[email protected]> >> > wrote: >> >> >> >> Gabriel - >> >> >> >> Hopefully Oren was able to give you some further advice on this - I >> >> like his idea of going with REST - that's the direction I'm pushing >> >> for currently, but I'm working with sensitive financial data so it's >> >> not an easy sell from the security perspective - still thinking about >> >> that one. In any event, the only code I have on hand is a really old >> >> spike but it shows the basic principle: >> >> >> >> public class TenantService : ServiceBase, ITenantService, >> >> ConsumerOf<GetCurrentTenantsResponse> >> >> { >> >> private readonly IServiceBus bus; >> >> private GetCurrentTenantsResponse response; >> >> >> >> public TenantService(IServiceBus bus) >> >> { >> >> this.bus = bus; >> >> this.bus.AddInstanceSubscription(this); >> >> } >> >> >> >> public GetCurrentTenantsResponse >> >> GetCurrentTenants(GetCurrentTenantsRequest request) >> >> { >> >> this.bus.Send(request); >> >> >> >> this.WaitForResponse(); >> >> >> >> return this.response; >> >> } >> >> >> >> public void Consume(GetCurrentTenantsResponse message) >> >> { >> >> this.response = message; >> >> >> >> this.NotifyResponseReceived(); >> >> } >> >> } >> >> >> >> You'd just need to add in a message interface that contains a >> >> CorrelationId (so all request and response messages would inherit from >> >> that interface) and then track that in the responses you get. >> >> >> >> HTH, >> >> Matt >> >> >> >> On Fri, Mar 13, 2009 at 3:27 AM, Gabriel Schenker >> >> <[email protected]> >> >> wrote: >> >> > @Matt: would you mind to share your code? >> >> > >> >> > On Fri, Mar 13, 2009 at 10:27 AM, Gabriel Schenker >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> inline >> >> >> >> >> >> On Fri, Mar 13, 2009 at 9:39 AM, Matt Burton <[email protected]> >> >> >> wrote: >> >> >>> >> >> >>> If you can use .NET 3.5 SP1, then you have the ability to use POCO >> >> >>> objects with the DataContractSerializer in WCF, so stand up a WCF >> >> >>> service that looks like >> >> >>> >> >> >>> [ServiceContract] >> >> >>> interface IMessageEndpoint: >> >> >>> [OperationContract] >> >> >>> object Handle(object message) >> >> >>> >> >> >>> Then in your implementation of the service you'd do >> >> >>> bus.Send(message) >> >> >>> in each operation and then the implementation class itself would be >> >> >>> a >> >> >>> consumer of all the response messages supported >> >> >>> (ConsumerOf<ListCustomersResponse> which corresponds to the >> >> >>> ListCustomersRequest message, etc...) >> >> >> >> >> >> isn't it possible with RSB to define a message handler that does not >> >> >> have >> >> >> to explicitly implement a ConsumerOf<TMessage> for every message it >> >> >> wants to >> >> >> handle but where I can rather handle ALL (or a filtered subset) of >> >> >> the >> >> >> messages? >> >> >> >> >> >>> >> >> >>> Up to now it's pretty clean, but >> >> >>> when you start talking about request-response scenarios it gets >> >> >>> messy. >> >> >>> We used a ManualResetEvent (just like in the Starbucks example) and >> >> >>> wait until that's been set by the Consume method for the reply >> >> >>> message >> >> >>> and then return that. Obviously you'll need to specify a timeout >> >> >>> that's reasonable for the operation (100 ms, 5 seconds, etc...) >> >> >>> >> >> >>> There's a major gotcha here - when you do bus.Reply in RSB it does >> >> >>> not >> >> >>> use the correlation ID of the message that was originally sent, so >> >> >>> it's up to you to maintain and check for a correlation ID in your >> >> >>> Consume method implementation. >> >> >> >> >> >> I don't understand this... If I use the correlation Id of the >> >> >> original >> >> >> message and provide it to the corresponding response message I >> >> >> should >> >> >> receive it back with the response? >> >> >> >> >> >>> >> >> >>> In a high load scenario who knows whose >> >> >>> reply message you're actually getting - sure it was sent back to >> >> >>> the >> >> >>> same box that originated the request, but it could be anybody's. In >> >> >>> the case where you got a message you don't want you do a >> >> >>> bus.HandleCurrentMessageLater() to put it back at the end of the >> >> >>> queue. >> >> >>> >> >> >>> I'm sure there's a more elegant way, but that's what we were >> >> >>> starting >> >> >>> to use until we discovered the correlation ID issue. >> >> >>> >> >> >>> On Fri, Mar 13, 2009 at 12:58 AM, Gabriel Schenker >> >> >>> <[email protected]> >> >> >>> wrote: >> >> >>> > >> >> >>> > We are implementing a distributed app with a Silverlight 2.0 >> >> >>> > client. >> >> >>> > The Web server forwards the calls from the client to an >> >> >>> > application >> >> >>> > server which sits behind a firewall. >> >> >>> > >> >> >>> > Question: >> >> >>> > -------------- >> >> >>> > what would be the easiest/most elegant solution to bridge the WCF >> >> >>> > calls from the Silverlight client into RSB. >> >> >>> > >> >> >>> > Sketch of the envisioned solution: >> >> >>> > ------------------------------------------------ >> >> >>> > My wish it is to have one single WCF service with a single method >> >> >>> > accepting "generic" messages (possibly serialized with the >> >> >>> > XmlMessageSerializer of RSB) and replying with a "generic" >> >> >>> > message >> >> >>> > response (also serialized with the XmlMessageSerializer). That >> >> >>> > would >> >> >>> > make the configuration of WCF very easy/slim... >> >> >>> > >> >> >>> > As soon as the message arrives at the WCF service I want to feed >> >> >>> > it >> >> >>> > into the bus. On the application server I then have the >> >> >>> > appropriate >> >> >>> > message handlers that consume the messages and reply with a >> >> >>> > message >> >> >>> > response. >> >> >>> > > >> >> >>> > >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> -Gabriel >> >> > >> >> > >> >> > >> >> > -- >> >> > -Gabriel >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
