Since crawlers and most bots don't use cookies, they create a lot of unnecessary sessions. At least for identified bots we'd like to avoid creating a session.
We're using SqlInMemoryProvider which doesn't appear to be open source.
https://cloudblogs.microsoft.com/sqlserver/2014/07/10/new-asp-net-session-state-provider-for-sql-server-in-memory-oltp/
Is there a way to run code to intercept session creation for certain conditions? My guess is one would need access to the custom SqlInMemoryProvider to achieve that. But maybe i'm missing something. ;)
Technology: Asp.Net Webforms, don't bother advising for MVC, thanks ;)
Answer for other people in my situation.
There are no hooks.
Everything needs to be done in the custom session-state store provider.
It's possible to use the free disassembler DotPeek by JetBrains.
One can dissassemble an existing state provider to c# code.
After that the code can be extended, for example detect known bots with a library (for example) https://github.com/totpero/DeviceDetector.NET and prevent such sessions from being created.
Related
We have existing ASP.Net Application 3.5. We have done Security Audit and we found that we can have XSS attack with our application.
As we have existing application and more than 100 modules - can we have easy way where with some configuration (minimal effort rather than going to every page and encode output).
We also have few pages where we need to allow even HTML Editor as well.
Please suggest me the easy and quick way to resolve this.
As we have existing application and more than 100 modules - can we have easy way where with some configuration (minimal effort rather than going to every page and encode output).
There are hacks, like the built-in ASP.NET “Request Validation”, or the “Security Runtime Engine” in MS Anti-XSS, which attempt to filter out what it thinks might be an attack on the way into your application.
These are generally a very poor solution in the long term, because they can't address all possible attacks and they'll break some input that isn't an attack. But this might be a useful temporary workaround measure until you can fix the app properly to escape everywhere it puts strings into a containing context, and set suitable development standards and controls to stop more context-naïve templating getting into the codebase.
We also have few pages where we need to allow even HTML Editor as well.
You will need an HTML sanitiser library to filter out all but acceptable whitelisted tags/attributes. Here is one.
I have been searching a lot for info and examples of the principles of making a simple multi-user web application.
The app i am going to make is used for deadline management and can be described as a simple calendar where users can register events.
I have no problem making this for a single user in PHP or ASP.NET, but how can i make this for multiple users, so they can register and only see their own data.
The app itself is pretty simple, and there will not be many users max. 50-100.
I find it hard to find info about this topic.
My own idea, which probably isn't the right way to do it is:
When a user creates an event, store it in a table with the user's ID.
When selecting data, use the logged in user's ID and get the corresponding event(s).
I would strongly recommend working within a framework in order to avoid re-inventing the wheel. If you know python, consider flask, pylons, or Django. If you would prefer to continue working in PHP (you should avoid working with ASP.NET if you are ever going to work with non-Windows developers) try Drupal. Ruby on RAILs has some options, as well, but I've never used it.
The way you are attempting to implement this is likely to lead to an oversized, overcomplicated database that is very hard for new developers to get used to. If you must implement this yourself, you should have a user/password table, an events table, and a table linking together the two (e.g assigning ownership).
We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I hesitate to make a decision about the authentication and authorization in a new web application.
The Membership, Roles and Profile built in Asp.net 2.0 seems impressive, but there are too many things behind them, which is uneasy to find out.
I've decide use my own DB structure so I have to rewrite my own provider, but there is still some thing I can't figure out, such as session and cookie.What, when and how does it encrypt and after retrieving user info from DB, seems cookie is uesed but how about session? I make use of MSDN, .Net Reflactor and Goole but get no answer. I mean I know the configuration and result but not sure how.
I don't think I can do a good job in the later improvement and maintenance if I don't know how the things process behind the Login controls and membership components.
So help me please, what should I do? I want to know how things run behind the screen. Any suggestion is looking forward!
You can download the source code for the providers here. Learn as much as you want from it and see how Microsoft implemented it. You might even want to recycle some pieces on the FormsAuthenticationTicket.
Microsoft's also using salted hashing to store the passwords for increased security. That might also be of interest to you when you make your own providers.
You should use .NET Reflector to find out how the .NET code works. You can also actually single-step into the sources in later versions of Visual Studio.