If not, are there any fundamental limitations of the service that prevent one from being built?
In response to Garys answer. "If you're hosting your app on EC2, it'll be fine"
Even if you're hosting your application on EC2 you should not really use SimpleDB to store session state. It provides an "eventually consistent" guarantee, so if you PUT something there is no guarantee that you will see the item on your next GET.
see: http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/index.html?EventualConsistencySummary.html
This is fine when you want to use simpledb to do indexing on data that does not need to be immediately up to date and can be reconciled later, but in the case of session state, you'd likely want something with ACID guarantees (like SQL Server) as you want to know that once you have committed something you will get it back on the next read.
This obviously depends on your requirements, but most people use session state to store shopping cart items or similar. Your site visitors will soon get upset if things appear to go missing from thier cart, then re-add them and then discover they have added the same item twice when they come to pay.
There's a C# library for working with SDB.
If you want to roll your own, the API, WSDL and other documentation can be found at http://aws.amazon.com/simpledb/#resources.
It's a pretty straight forward API that rides over HTTP. The hardest part is writing the signing code. There's plenty of implementations in other languages.
As for using it for session state, there's a huge speed difference between using SimpleDB from EC2 and anywhere else on the internet. If you're hosting your app on EC2, it'll be fine, otherwise, it'll be brutally slow.
You could base it off this MySQL provider:
http://harry-kimpel.spaces.live.com/Blog/cns!CAA619CB4C4D1B6C!342.entry
Related
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
Is there a way to see who is currently logged in to a Plone site?
Rationale: I want to make sure not to interfer with users working on content when I restart the instance.
Out-of-the-box, there is no way to see if users are currently using your site, only if they have just been using it. Just tail the instance-Z2.log access logfile.
Note that due to the nature of the HTTP protocol, 'current' users of your site do not maintain a connection, and thus, until they are back again for the next request, there is no accurate way to determine if anyone is using the site.
There are work-arounds, such as using sessions and timeouts, that use recency to estimate how many users are still around. collective.portlet.usertrack is one such approach. Note that such approaches can have a hefty scalability penalty though.
If all you want to do is not inconvenience users during a restart, use a caching frontend and / or a load balancer and more than one instance instead. That way users see cached content or content generated by an instance still up while you restart your first instance.
you can try collective.portlet.usertrack
I build ASP.NET websites (hosted under IIS 6 usually, often with SQL Server backends and forms authentication).
Clients sometimes ask if I can check whether there are people currently browsing (and/or whether there are users currently logged in to) their website at a given moment, usually so the can safely do a deployment (they want a hotfix, for example).
I know the web is basically stateless so I can't be sure whether someone has closed the browser window, but I imagine there'd be some count of not-yet-timed-out sessions or something, and surely logged-in-users...
Is there a standard and/or easy way to check this?
Jakob's answer is correct but does rely on installing and configuring the Membership features.
A crude but simple way of tracking users online would be to store a counter in the Application object. This counter could be incremented/decremented upon their sessions starting and ending. There's an example of this on the MSDN website:
Session-State Events (MSDN Library)
Because the default Session Timeout is 20 minutes the accuracy of this method isn't guaranteed (but then that applies to any web application due to the stateless and disconnected nature of HTTP).
I know this is a pretty old question, but I figured I'd chime in. Why not use Google Analytics and view their real time dashboard? It will require minor code modifications (i.e. a single script import) and will do everything you're looking for...
You may be looking for the Membership.GetNumberOfUsersOnline method, although I'm not sure how reliable it is.
Sessions, suggested by other users, are a basic way of doing things, but are not too reliable. They can also work well in some circumstances, but not in others.
For example, if users are downloading large files or watching videos or listening to the podcasts, they may stay on the same page for hours (unless the requests to the binary data are tracked by ASP.NET too), but are still using your website.
Thus, my suggestion is to use the server logs to detect if the website is currently used by many people. It gives you the ability to:
See what sort of requests are done. It's quite easy to detect humans and crawlers, and with some experience, it's also possible to see if the human is currently doing something critical (such as writing a comment on a website, editing a document, or typing her credit card number and ordering something) or not (such as browsing).
See who is doing those requests. For example, if Google is crawling your website, it is a very bad idea to go offline, unless the search rating doesn't matter for you. On the other hand, if a bot is trying for two hours to crack your website by doing requests to different pages, you can go offline for sure.
Note: if a website has some critical areas (for example, writing this long answer, I would be angry if Stack Overflow goes offline in a few seconds just before I submit my answer), you can also send regular AJAX requests to the server while the user stays on the page. Of course, you must be careful when implementing such feature, and take in account that it will increase the bandwidth used, and will not work if the user has JavaScript disabled).
You can run command netstat and see how many active connection exist to your website ports.
Default port for http is *:80.
Default port for https is *:443.
I am looking into different ways to handle updating an ASP.NET application across many different clients, and looking for suggestions from your previous experience.
We need the client apps to check if they have any available updates.
A way to Auto update (If possible, something similar to chromes but for webapp).
Some way to check that we are the ones sending the updates. (Checksum of some sort I would guess)
Any other tips/advice
Thanks
Edit: after thinking more about this overnight, I would have to agree that auto updates may not be the best. However maybe something more along the lines of how wordpress does it. Wordpress will display saying that there is an update available then clicking will auto update the system.
I would absolutely not have your application auto update on clients (assuming you mean clients are entities external to your organization) servers. We would immediately stop using a product that would "phone home" and update itself. Clients need to be able to choose when and how an update on their server occurs.
If you are going to do this, the easiest way would be to set up URI the systems could ping once a day etc. and see if there are updates available. If so the application would pull it down from the host system and update itself. If you do it using SSL then the certificate would verify the URI being hit is your company.
Having a hard time figuring out if you're actually talking about a web application or a desktop application. If you're trying to do something similar to Chrome...I'm guessing a desktop application. If that's the case...check out ClickOnce deployment.
It offers the first three bullet points you mention:
Every time a person runs the app, it will check for updates.
If updates are found, the user can choose to install them or not (better user experience than forcing the update on the user).
The application always checks the URL that the app was installed from...which in your case would be your servers.