locked
What happened to the Web app Logout? RRS feed

  • Question

  • What happened to the Web app Logout for Forms Authorization?

    How are users supposed to log out from the web app when they are done. 

    NOTE:  We are testing now with Azure and our servers to determine if Azure is a better solution for us.

    We have users that share a computer with the same login.  However, they all have their own logins to our LS apps.

    With Azure, LS is logging users in using the credentials from the last user. 

    Please advise how we can log out from an LS web app.

    Tuesday, March 29, 2011 10:14 PM

Answers

All replies

  • Garth, logout feature has been cut. There are two ways to logout:

    1. Close all instances of the browser.
    2. Timeout (IIS or web.config)
    Tuesday, March 29, 2011 10:20 PM
  • interesting.  Mine asks for credentials each time...but then again i can't access any data for some reason so...
    Tuesday, March 29, 2011 10:21 PM
  • interesting.  Mine asks for credentials each time...but then again i can't access any data for some reason so...


    Close all instances of the browser, start a new one and access the app. Here it is expected to show the login page. If all instances of the browser were not closed then accessing the app from a new window or tab will be allowed. This is the behavior of any ASP.NET app that uses cookies.

    Do you see Login page or Windows credentials dialog? If you are using Firefox then you probably get a Windows credentials dialog. Please look at this thread: http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/bc4ba9db-2044-4745-8254-b5f083c685b6

    Please could you let me know what happens when you get past the login. Does the Navigation menu, Command bar and screens load correctly?

    Tuesday, March 29, 2011 10:41 PM
  • Yes everything loads correctly for me except the data...i have another post about it:

    http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/e6dc8176-b5da-4c7f-8909-f6ee88819179

    Tuesday, March 29, 2011 11:08 PM
  • @Ravi and the LS Team:

    We are writting secure biz apps.  There must be a prominent way for the user to logout of an LS application.  

    Can we programatically add a Logout button to the new User Name dropdown to logout?  The only current option for the user name dropdown is to change their password (its in the lower right hand corner).

    Many thanks for your consideration of this important issue.

    Tuesday, March 29, 2011 11:32 PM
  • I think the answer 'has been cut'  is to  simple,  the basic of any business apps there business rules to follow like audit management.

    The answer you can build that yourself is also a nodo answer.


    Eric
    Tuesday, March 29, 2011 11:34 PM
  • Garth, logout feature has been cut. There are two ways to logout:

    1. Close all instances of the browser.
    2. Timeout (IIS or web.config)

    Every time i see stuff like this i just have to shake my head and wonder about how many things V1 is missing...

    this really reminds me of Silverlight V1 - i did not even start to use it till V3 cause V1 was a joke, should have never been published.

    I really wonder if this will get a second release, with so many things missing i can see a lot of folks just watching and passing on V1 with a hope that V3 will not take to long...  at this time V1 seems like it's going to be lacking to many key features to really use for many things....

    Tuesday, March 29, 2011 11:39 PM
  • I must say I'm quite baffled by the decision to not allow logging out.  I mean every web application on the planet allows you to choose to log out.  Yes it might be nice to have automatic logging in if you want it...But no way to log out on demand....that's weird.  And a strange decision to cut it as a "feature."

     

    I can sense your frustration creeping in Figuerres...or maybe that's me just projecting my own frustration that is building rapidly as i keep running into problems.

    Tuesday, March 29, 2011 11:47 PM
  • I had not even considered "logging out" at this point as I would have thought it was a no-brainer until I read this thread.

    Not being able to log out from a LS application is a show-stopper for me. I cannot tell my user to "close all instances of their browsers" to log out.

    LS team: please reconsider this.

    edit: see my next post two down

    Thanks in advance


    Xander
    Tuesday, March 29, 2011 11:52 PM
  • @figurres:  Keep in mind that this was a feature in B1. 

    By design, LS v1 will not be scalable.  Therefore we will have to go old school and use several LS apps to make up a suite.   Therefore the logout functionality is absolutely imperative. 

    Our company wants to host our apps with Azure.  It is my understanding that charges are based on user login time (I could be wrong as the Azure billing is complex).

    Users will have several LS apps up at the same time (GL, AP, Inventory, etc.).  It is not possible for them to close all browser instances when they are through with a modular application.

    If a logout function isn't included in LS, Azure will not be an affordable option for LS hosting.   Please enlighten me if I am mistaken here. 

    Even WP7 apps all have logout buttons, yes?  That flashlight white screen as a profitable app still amazes me.

    Tuesday, March 29, 2011 11:55 PM
  • @Garth: thinking some more about it, hosting the LS app inside an ASPX page will allow us to add a [Logout] link in the ASPX page and we should be able to log out from there. This may just be a work-around.

    Edit: and in fact, will that not provide you with a nice launching pad for all your different LS modules by having links to each module embedded in the ASPX page like a "menu" of sorts?


    Xander
    • Edited by novascape Wednesday, March 30, 2011 12:02 AM
    Tuesday, March 29, 2011 11:58 PM
  • But what if there is no other apps then LS?
    Eric
    Wednesday, March 30, 2011 12:01 AM
  • if the definition of LS functional market is bizz apps, that is oke with me. Clear not ALL can be done in the same time for V1 release .It  is a matter of choices, but the argument we have a small team and limited resources is not  a correct answer
    Eric
    Wednesday, March 30, 2011 12:02 AM
  • There are business types that will not allow the use of cookies as LS is using by default but use session id /user etc  how to handle this in a 2/3 architecture deployment solution?
    Eric
    Wednesday, March 30, 2011 12:14 AM

  • Our company wants to host our apps with Azure.  It is my understanding that charges are based on user login time (I could be wrong as the Azure billing is complex).

    Users will have several LS apps up at the same time (GL, AP, Inventory, etc.).  It is not possible for them to close all browser instances when they are through with a modular application.

    If a logout function isn't included in LS, Azure will not be an affordable option for LS hosting.   Please enlighten me if I am mistaken here. 

    Azure charges are not based on log-in time.  They are based on deployed time.  It's pretty misleading the way they price things.  Essentially your app is charged compute time for every hour it is deployed..even if it's in staging...and even if it is stopped.
    From the sound of it your Suite of Apps will be pretty expensive on Azure....roughly 100 bucks a month per App in a small instance role....Consider using extra small instances instead..and or  consolidating your apps. 



    Wednesday, March 30, 2011 12:18 AM
  • @figurres:  Keep in mind that this was a feature in B1. 

    By design, LS v1 will not be scalable.  Therefore we will have to go old school and use several LS apps to make up a suite.   Therefore the logout functionality is absolutely imperative. 

    Our company wants to host our apps with Azure.  It is my understanding that charges are based on user login time (I could be wrong as the Azure billing is complex).

    Users will have several LS apps up at the same time (GL, AP, Inventory, etc.).  It is not possible for them to close all browser instances when they are through with a modular application.

    My recollection is that the problem with including a logout button is that we couldn't do it in a way that worked securely in 100% of cases.

    There isn't a reliable "tear down everything and start over" feature in Silverlight.  so we cannot do a "logout" which stays inside the the SL player.  The only way to be sure is to force-reload the SL control.  We can do that inside a browser with javascript.  But we cannot do that in 2T or 3T desktop, as there is no JS engine available to us.

    For desktop apps, close the frame.

    For browser apps, provide an ASPX wrapper or a special "logout" page link.

    There were things that we "put out there" in Beta1 that didn't actually work and we didn't realize it until later.  That's why Beta2 is missing features that Beta1 had. 

    Wednesday, March 30, 2011 1:19 AM
  • Ravi,

    "logout feature has been cut" - if this means that a functioning feature, that existed in B1, was cut from B2, (without checking to see if it was needed) this is sheer lunacy!

    Not being able to "log out" & have a different user "log in" to your app, if you're using Forms Auth, is just rediculous. SharePoint allows you to do it. I assume that ASP.NET allows you to do it, & I think even MVC.NET allows you to do it. Every website, that has authorisation, that I've ever seen allows you to do it. Even MS Access will allow you to program for this!

    I use Windows auth & it's an OOB app, so this doesn't affect me so much (yet!), but it's unbelievable to have a non-windows way to authenticate & then expect users to close every IE window they have open (a lame answer at best), or worse wait for a timeout (what kind of nonsense answer is that?!!).

    Personally, I think Silverlight was the "wrong" choice for a client in the first place (but I'm biased), I would have much preferred WPF. Though I do accept that many people will like a SilverLight app. I wouldn't want to see that taken away from them.

    But it's becoming apparent that there are a number of reasons that SilverLight is just not going to work for everyone, this logon issue being one of them, & the main other one is businesses that won't allow the SilverLight plug-in to be installed.

    So, it would be a very "prudent" thing for LS to allow the *option* of generating a WPF app, SL is after all a subset of WPF, so I don't see why it would be all that difficult. Happy to be corrected though if there is a valid *technical* reason. Please! Nobody even *think* of trying to give me a *marketing* rationalisation for why this can't be done!

    Yann

    Wednesday, March 30, 2011 2:42 AM
  • I believe one of the reasons why this was removed is that we cannot guarantee that stale information is not left in the application when a use logs out of the application. For example, static classes or static members of classes can hold onto information even if core part of the application is torn down.

    Normally, the way you could guarantee that an application no longer has any context is to load it into a separate AppDomain, run the application (whatever it needs to do), and then tear down the AppDomain upon completion (in this case, upon logging out). This unloads any assemblies that were running in that AppDomain.

    It looks like Silverlight allows for creating a separate AppDomain other than the one that is provided by default when you execute a Silverlight application, but it does not look like Silverlight allows for remoting of objects from one AppDomain to another. I think this would be required if we wanted to provide this isolation (to allow for complete deconstruction of the application that contains user code) but still be able to host the UI in the primary AppDomain (so that the end-user actually has a visualized application to interact with).

    Wednesday, March 30, 2011 3:18 AM
  • Hi Justin,

    Thank you for taking the time to explain what happened & why. It's appreciated.

    But let me ask you a question? Do you really think it's acceptable to just rip something out that people might need, with no warning, no explanation & no (reasonable) suggestions on how to handle the situation?

    This sounds like a huge fundamental flaw in SilverLight to me (but I like I keep saying, I'm NOT a SL developer). Does this mean *all* SL apps suffer from this "problem"?

    Surely there would have been an uproar from SL developers if that was the case, therefore I suggest that there MUST be an answer to this problem somewhere.

    Yann

    Wednesday, March 30, 2011 3:38 AM
  • I still don't quite understand why the application can't be put into some kind of modal state with the login screen showing if someone clicks a "log out" button that would close all open screens...and require re-authentication to continue.  I understand that complete deconstruction of the app might not be possible  but is that necessary to say... switch users?   
    Wednesday, March 30, 2011 4:20 AM
  • I still don't quite understand why the application can't be put into some kind of modal state with the login screen showing if someone clicks a "log out" button that would close all open screens...and require re-authentication to continue.  I understand that complete deconstruction of the app might not be possible  but is that necessary to say... switch users?   


    We didn't think it was acceptable to allow for the possibility of dangling state when switching users.  Specifically things like event handlers.   Because there isn't a guaranteed tear-down, we can't guarantee that User A's stuff is really "gone" when user B starts using the app.  You might be subject to strange performance problems, or even worse, data corruption issues.

     

    Wednesday, March 30, 2011 4:28 AM
  • Hi Matt,

    I can understand the concern. But do you think it's an acceptable alternative to just leave users with no way of logging off?

    How do other SL apps handle this situation? I find it hard to believe, as I stated above, that SL developers wouldn't have run into this & would either have found a way to handle it, or kicked up a huge stink (or just not used SL at all).

    Yann

    Wednesday, March 30, 2011 4:48 AM
  • Hi Matt,

    I can understand the concern. But do you think it's an acceptable alternative to just leave users with no way of logging off?

    How do other SL apps handle this situation? I find it hard to believe, as I stated above, that SL developers wouldn't have run into this & would either have found a way to handle it, or kicked up a huge stink (or just not used SL at all).

    No, we don't like it, and we'd like to do everything for every one of our customers in V1.  And one of the extra rotten things about doing betas is we show you stuff and then have to take it away later.  Sorry about that :)

    It's actually not really fair to say there is NO way to logout; For desktop apps, just close the window.  For browser apps, it depends on your browser as far as frame close / tab close behavior, but you can certainly create an ASPX page or control which works for all of them. 

    Neither of these situations are actually new or unique to LS apps -- closing the app window is the only supported way of logging out for all kinds of commercially viable apps.  It's certainly not as nice as having a Logout button built right into your shell that "just works", but I think you guys as developers will be able to come up with solutions that your users can understand and live with.

    We had a logout button in Beta1 because we knew that was something people might want, and we are trying to make it as easy for you to focus on your apps and not have to worry so much about plumbing.  But part of "not worrying" is not worrying that we've done it wrong, badly, unreliably, or worst of all, insecurely.

     

    Wednesday, March 30, 2011 5:11 AM
  • Could you just spawn a new instance entirely?
    Wednesday, March 30, 2011 5:13 AM
  • Hi Matt,

    Yeah, OK, you guys are stuck between a rock & a hard place sometimes, aren't you.

    I'm NOT a SL developer, so I admit I don't know what users of SL apps have to put up with, & what they find "acceptable".

    But I do stick with what I said before, sorry, that if you can log IN you should be able to log OUT & someone else log in. Your B1 instincts were right, lol. I do understand that things have to change in betas, it's just when it's really basic stuff that an app NEEDS (yeah I know, according to who), that it's a bit hard to swallow.

    You know, it's all these kinds of "restrictions" that SL (not so much LS) seems to have that REALLY makes me wish that it was a WPF client instead, or at least that there was the *option* to generate a WPF client. I don't develop web apps because I don't like all the things that a web app can't do.

    Thanks for taking the time to explain the situation,

    Yann

    Wednesday, March 30, 2011 6:23 AM
  • Closing the tab is totally acceptable log out for me...i just don't want to be automatically logged back in if i reopen the site in a new tab.
    Wednesday, March 30, 2011 6:35 AM
  • But let me ask you a question? Do you really think it's acceptable to just rip something out that people might need, with no warning, no explanation & no (reasonable) suggestions on how to handle the situation?

    Well, remember the "Ah, by the way, your Beta 1 projects won't work" - thingy... ;o) The Information policy is really really... well... sometimes I think there isn't really one.

    I'd like some kind of documentation for LS, not only "HowTo's" and Walkthrough and Tutorials and so on. We are your Betatesters, Microsoft, and we really need some docs and better information. Come on, Microsoft, we are on the same side!

    Wednesday, March 30, 2011 10:55 AM
  • Hi Matt,

    I can understand the concern. But do you think it's an acceptable alternative to just leave users with no way of logging off?

    How do other SL apps handle this situation? I find it hard to believe, as I stated above, that SL developers wouldn't have run into this & would either have found a way to handle it, or kicked up a huge stink (or just not used SL at all).

    No, we don't like it, and we'd like to do everything for every one of our customers in V1.  And one of the extra rotten things about doing betas is we show you stuff and then have to take it away later.  Sorry about that :)

    It's actually not really fair to say there is NO way to logout; For desktop apps, just close the window.  For browser apps, it depends on your browser as far as frame close / tab close behavior, but you can certainly create an ASPX page or control which works for all of them. 

    Neither of these situations are actually new or unique to LS apps -- closing the app window is the only supported way of logging out for all kinds of commercially viable apps.  It's certainly not as nice as having a Logout button built right into your shell that "just works", but I think you guys as developers will be able to come up with solutions that your users can understand and live with.

    We had a logout button in Beta1 because we knew that was something people might want, and we are trying to make it as easy for you to focus on your apps and not have to worry so much about plumbing.  But part of "not worrying" is not worrying that we've done it wrong, badly, unreliably, or worst of all, insecurely.

     

     

    Matt:  part of what really gets me is that i and others made a number of requests and comments for LightSwitch in the very start of B1 and so far all i have seen is MSFT replying with one or more of the following:

    We will not do that in V1

    We can't do that

    or no reply at all....

    I know that not everything can be done in V1

    but i get the feeling that *NOTHING* we have asked for will be done in V1 because some managers @ MSFT just do not care what we say.

    so we keep writing code with other tools .... I grow less and less interested in this one every day.

     

     

    Wednesday, March 30, 2011 1:00 PM
  • *signed*

    Although it's not fair to state that nothing got done, but, well... yeah, somehow you're right.

    Wednesday, March 30, 2011 1:27 PM
  • *signed*

    Although it's not fair to state that nothing got done, but, well... yeah, somehow you're right.

    To be fair and to try and make this clear:

    It's the "Feeling" based on how the Microsoft Lightswitch Team has communicated with the customer.

    I am sure that a *LOT* has been done, I am sure that folks are honestly working to build a great product.

    it's the way they have failed to really work with us, the customer that is the first problem.

    the second is that I can not tell if they have taken any of our feedback into the product.

    I get the impression that they seem to think that they "know what's best for us" and that is just not right.

    many of us who have been posting here are professional developers with years of real world exp. in building business applications.

    we like the concept of "LightSwitch" but we see that it does not have some features and options that we see as critical to our ablilty to use it and sell it to our clients.

    when we bring this up and find that we are not getting useable answers we are forced to draw our conclusions about how the managers are handling this.

    there are a number of simple things that have been posted in connect that have went on for months with no further comment from MSFT in connect and here.

    by way of example I posted in connect about some of the data type issues that are common to LOB and my post and others have over 30 votes.

    but no reply from MSFT ...

    We are the customer, we are telling you what we need, if you do not listen and act on that then you are not delivering the product we need.

     

    Wednesday, March 30, 2011 2:10 PM
  • I totally agree with you. ;) Let's see if we'll get some response...
    Wednesday, March 30, 2011 2:48 PM
  • Closing the tab is totally acceptable log out for me...i just don't want to be automatically logged back in if i reopen the site in a new tab.


    Unfortuneately, that is a function of browsers and cookie handling.  The "are you still logged in" behavior is different between IE8 and IE9 even. 

    to be absolutely sure in forms-auth browser scenarios, you'll need a button somewhere that destroys the session cookie.

    Wednesday, March 30, 2011 2:54 PM
  • Please keep in mind there are real people on the other end of these comments we are making.

    "it's the way they have failed to really work with us, the customer that is the first problem" kinda hurts when MSFT I am sure feels that they have. They have explained the exact situation.

    Perhaps something can be done in the future.

    However, can we please be nice :)


    http://www.adefwebserver.com

    http://lightswitch.adefwebserver.com

    Wednesday, March 30, 2011 3:10 PM
  • Hi Michael,

    I'm not seeing anyone "not being nice", what I am seeing (& often feeling myself) is "real" people on *this* end with "real" concerns & "real" frustrations.

    I feel for the LS team, I really do. They've done some *wonderful* work, but also have had to make some "dubious" decisions based on constraints forced on them no doubt by "Marketing" etc.

    But if the "basics" aren't right, people can't use the product. Publishing to Azure might tick a marketing box, but not being able to log out doesn't tick a real-world box. And the list goes on.

    I don't think anybody wouldn't agree that the team is doing great stuff. It's the constraints being imposed on them, or the limits of the technology chosen for the client, that will often be causing their inability to do what we say we need. But we still need what we need. I'm sure if they could, they would give us *everything* we want/need. I hope we all understand that.

    But if we don't voice our frustrations & concerns, some of us (me especially) a little less PC than others may want, then the team is not going to know what's going on "out here".

    Yann

    Thursday, March 31, 2011 12:03 AM
  • To echo Michael, "However, can we please be nice :)"

    A simple question was asked and answered by Ravi in an honest straightforward manner. Matt and others from the team have jumped in and provided rationale behind the decision to remove the Web logout. Yet somehow this thread has turned into a firestorm bringing up numerous unrelated issues.

    For other forum users simply seeking an answer to a simple question, this is distracting at best. I would ask that in the future if you wish to discuss issues about missing features, opinions about how things should have been implemented, and so on, please open a new discussion thread.

    I don't want to discourage open discussion, in fact I rather enjoy it - but please keep the discussions in their proper place.

    Regards,


    Steve Hoag Microsoft aka the V-Bee
    Thursday, March 31, 2011 12:57 AM
    Moderator
  • Instructing users to close all instances of the browser, and start a new one to reset login credentials is a complete non-starter. It's a deal-breaker. Users might be holding content in another tab or browser window they want to refer to, such as an open GMail window with a Google Voice number running, for incoming calls. What you suggest is impossible for such a person, since his calls  will be disconnected if he closes all his browsers!
    -- Rob
    Tuesday, April 5, 2011 12:38 AM
  • Instructing users to close all instances of the browser, and start a new one to reset login credentials is a complete non-starter. It's a deal-breaker. Users might be holding content in another tab or browser window they want to refer to, such as an open GMail window with a Google Voice number running, for incoming calls. What you suggest is impossible for such a person, since his calls  will be disconnected if he closes all his browsers!
    -- Rob

    Thanks Rob. I understand and strongly support your concern.

    Please could you give me a scenario where you want to log out of a LightSwitch app as User 'A' and login as User 'B'? How often would this happen? Do you use different browsers (Firefox, Chrome, etc.) so that you can open the second instance of the app in the other browser? I ask since I am gathering scenarios that will help me bump the priority in getting the issue fixed.

    Tuesday, April 5, 2011 2:54 AM
  • Ravi,

    I am assuming the issue is only with the web deployment scenerio. If so i could easily make a button that called a ASP.NET Forms logoff:

    FormsAuthentication.SignOut();
    
    If so perhaps the team could just post a blog on how to add this to a deployed application.

    http://www.adefwebserver.com

    http://lightswitch.adefwebserver.com

    Tuesday, April 5, 2011 3:18 AM
  • Ravi,

    I am assuming the issue is only with the web deployment scenerio. If so i could easily make a button that called a ASP.NET Forms logoff:

    FormsAuthentication.SignOut();
    
    
    If so perhaps the team could just post a blog on how to add this to a deployed application.

    We're actually about to release a sample that does exactly that -- lets you make an LS button which does a logout and dumps you back at the LS login screen.

    Tuesday, April 5, 2011 4:13 AM
  • The simplest scenario is the one a project specifier will insist upon for any secured data: A logout which clears access to the data is required. Or: A timeout which clears access is required. 

    Without supporting such a function, there are *no* instances in which I can imagine that, for only one example, an application accessing HIPPA (medical) data would ever be authorized, let alone written. Financial data access would be another. Human Resources data, a third. We aren't really talking about use cases here where we swap users in these kinds of data scenarios; they're conditions where some overarching privacy law governs the workflow: walk away from the desk or remain idle for time "t", and the app MUST be logged out!

    But, to satisfy your request, the simplest use case is that of an IT professional checking the function of an app on a deployed machine, with test accounts. I've already encountered situations where I got odd login problems because IE wasn't configured properly. 

    If you don't think those use cases are important, then you haven't been in the trenches long enough to see how IT departments verify app installations. 


    -- Rob
    Tuesday, April 5, 2011 7:26 AM
  • Yes, you did. But, that's not an *LS* logout button. 
    -- Rob
    Tuesday, April 5, 2011 7:30 AM
  • Sooner the better, Matt. It's the only thing keeping me from a dogfood deployment to 18 users on four continents. And, yes, I'm talking about an in-browser use case. 
    -- Rob
    Tuesday, April 5, 2011 7:31 AM
  • Thank you Rob for your explanations.  Biz app developers are biz app developers because we know all of this - it is expected (demanded) of us.  The purpose of .NET is to support complex and massive business and government.  Everyone that has spend 10+ years of implementation with SAP, JD Edwards, and the MS Dynamics Suites know what are requirements for biz apps.   Everyone that has worked for a number of years in an IT department for a company that had more than 1000 employees know.   Biz app developers know accounting.  We know operational business processes.  We know how to reengineer a business to be more profitable.

    We are only now at the very beginning of an exciting evolution of .NET for business with SL/LS and everything .NET.

    A company web site, web store front, and stand alone CRM system are just a very small part of the software required to run a business.  However, these components are very necessary. 

    LS is the right direction with SL as an intelligent web/desktop client for mainstream biz apps.  To be very clear, LS/SL is NOT the right technology for all business needs.  LS/SL biz apps need to integrate with ASP.NET.  It shouldn't be that difficult to make everything .NET a seamless environment.  Yes, HTML5 is a blessing.  Check our Razor.

    .NET started ~1998.  It has been a long and hard road to get to where we a now:  on the treshhold of biz app development that will globally evolutionize the way we live.

    We are creating a rapidly growing consensus with LS of what the requirements are for a modern biz app develop system as we develop apps. 

    Bottom line, our LS community is facing incredible life opportunities. 

    Tuesday, April 5, 2011 6:28 PM
  • Sooner the better, Matt. It's the only thing keeping me from a dogfood deployment to 18 users on four continents. And, yes, I'm talking about an in-browser use case. 
    -- Rob

    http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/13b2adcf-aacc-49fb-83b8-7c0c70466a85

    Tuesday, April 5, 2011 6:30 PM
  • Weeeelll, that looks like it works OK. Except I don't know how to inject it into an Azure deployment. 
    -- Rob
    Wednesday, April 6, 2011 12:16 AM