This is a pretty basic question.
Since browsers have a culture setting that the web app uses to decide which locale to use, should I still have a "language" button for users to be able to override the culture?
Why or Why Not?
To me it doesn't make sense to have a button there if the user had already set their language in their system.
Yes, you should.
One of the reasons outlined on the ASP.NET Localisation page is that a user may have a preference for reading certain types of websites in a specific language (i.e. technical websites in English). This is a good reason.
There are other reasons as well (i.e. the translation may not be great, a different user than typical is using the given computer, etc, etc).
Related
So I may have a bit of a strange situation here, and I need some guidance.
The company I work for has a number of small sites, with each site selling a different custom program. The sites are badly in need of an entire rewrite from top to bottom, and my boss has agreed that a login and online purchase/registration is required. This means user accounts, the ability to download a trial from within the user account, the ability to register that trial also from within the user account and the ability to view a list of previous purchases/registrations and product keys.
The thing is, I want a sign-on from one site to be usable on another. Plus, all of this will need to be administered (on our end) from one admin interface. So my thought is that this will all have to be driven by a single database.
Just to be clear: the front-end for each site needs to be different - sometimes only subtly, but in some cases by quite a bit (marketing differences). The backend (both Admin as well as for the Client interface), is identical in structure regardless of the site URL, but the Client interface needs to show different content (programs to download, lists of computers where the program has been registered on, etc.) depending on what URL is being used.
My problem is that I am not entirely sure how to do this from a code-first perspective. The sites are small, quite easy to build on their own, but I want them all within the same Solution so that a change to the model will be reflected across all of them (I will be able to see where things go sideways if the model gets altered - Intellisense is my friend!).
I have looked into Areas, but Areas seem to be a way of partitioning off gross differences within a site (things like resource files - JavaScript, CSS, etc. - remain in the root, whereas in my case each site will need different resource files). I need each section to be its own unique site, with its own unique URL. When this gets pushed to the server, I need each site to be “independent” in that they can sit in entirely different accounts on the same Windows Plesk server (Plesk was not my choice, but the company has clients that need a control panel interface to their own accounts). The only strong commonality between any of them is the database that they will make use of -- in fact, all of them will be making use of the same tables, with very few differences between the sites.
My other problem is that I do not know how to properly implement having multiple projects within a single solution, and all projects making use of the same model that is implemented/constructed only once. I have not yet made the jump to Repository Patterns, so I am completely in the dark with respect to that functionality.
If anyone has a suggestion, I would love to hear about it.
Essentially, you just need to create a class library where you will put your entities and context. If you're using Identity, you'll also put all the Identity-related entity classes here. You'll enable migrations on this class library. The other projects in your solution, then, will have a reference to this class library. You'll need to add the connection string to the individual projects' Web.config files, but other than that, everything will just work.
This is enough to ensure that all the projects are working from a common database and user store. However, in order to actually share authentication, such that signing into one, signs you into all them, you'll have to take one of two paths, depending on how they will be deployed.
If all of the sites will be on the same domain (different subdomains are fine). Then all you need to do is generate a machine key and ensure that each site uses the same machine key in its Web.config. The auth cookie will be added on the wildcard domain, and any subdomain of that domain will be able to see it. Sharing the machine key is to ensure that they can each decrypt it what any one them sets as the auth cookie.
If not all the sites will be on the same domain, then you're in for some pain. You'll have to set up a SSO system, which is non-trivial and far beyond the scope of Stack Overflow to help you with. There's entire companies devoted just to building SSO systems for organizations.
I need to develop a web based product. Features of this will be available to users based on subscription categories like Basic Version /Premium Version / Enterprise Version. I would like to maintain single source for these subscription categories.
Here my question is,
How to design web application, which has features enabled based on configuration / subscription categories?
Thanks in Advance
This is very general question, and I will answer generally.
You can assign Roles to your registered users, and then you check using the IsUserInRole to
see what you going to show and what not.
To gain speed you can assign the permission to the user session and not always call the IsUserInRole
You can open and close some part of your page using the Panel and the Visible of it. Also close the Viewstate of the Panels that are hidden.
Alternative you can use UserControls that inside of them you check if the user have permission to see it or not, and you hide it OnInit, and also disable the ViewState of it.
And of course if a full page is not permitted you can always make a full redirect.
So a full page can have Panels, and UserControls, and the views of it depend from the user level.
You will not be able to get this readymade , you have to design the application based on the technology you are using.
I had similar kind of project going on in which we store the list of feature in database and when the page initializes loads the feature list in session.
On various pages we are showing/hiding controls based on the feature availability.
Offcourse Single feature can also have category based on the User Roles that we can check using FormAuthentication methods and change the page server side accordingly.
Let me know if you have any specific approach in mind and have question related with it.
ASP.NET has build-in functionality to automatically load the correct language resource file based on the browser's preferred language.
For example, if a visitor has Danish (da) as his/her preferred language, and the website has a *.da.resx file, then that resource is used. When the preferred resource file is not available, ASP.NET falls back to the basic/default resource file (*.resx).
Now, browsers allow for more than one preferred languages to be specified. If the visitor would speak Danish, but added Norwegian as a second language to the browsers preferences (written Norwegian is 95% identical to Danish), then the browser would send "da,no;q=0.9" to the web server. However, it seems this secondary language is not supported by ASP.NET; *.no.resx will not be loaded if *.da.resx is not available.
Does anybody know how to support secondary languages?
Note that ASP.NET only automatically processes the first entry in the accept-languages header field to determine which culture to use if enableClientBasedCulture is enabled in the web.config file.
If you wish to extend this and examine other language entries (if any) in the accept-languages list to see if you have a match, you will have to do it programmatically and set the Thread.CurrentThread.CurrentUICulture(which the ResourceManager uses to find the appropriate localized resources) and Thread.CurrentThread.CurrentCulture (which will control how locale-aware datatypes will be presented and processed). This is explained here.
I have a website with a flex application. The flex application has no user input - except for clicks for navigation. The website also uses no scripting language - i.e. no php, asp, jsp or cfm.
The website just consists of one page which contains the flash file for the flex application. The source code of this page is here: http://pastebin.com/n5b4RxqT
I have been advised (by a software program used by my client) that this website is vulnerable to a reflective type XSS attack and have been advised to 'sanitize' all user input.
I am a noob with respect to XSS and would respectfully like to ask that AFAIK there is no user input. What should I sanitize and how?
Thanks in advance
Using AC_OETags is the old way of doing things and is deprecated. What you want to do is use SWFObject which is now the default in Flash Builder 4.
The reason why I ask is that I'm telling a vendor of ours they have to use the MS AntiXSS library with the ASP.NET UI components they make, but they also work with Flex to build Flash based UIs - and I was wondering if there's an equivalent for Flash (assuming it's vunerable).
If I understand correctly...
ASP.NEt is used to make web pages, and all UI Components they make will be running in a browser as HTML / JavaScript. Is that correct?
If that is the case, I can understand why preventing cross site scripting would be important in that case.
With Flex (which runs in the Flash Player), everything is compiled down into a binary file, called a SWF. Most of the time, the SWF runs inside the Flash Player, which runs in the browser as a plugin. There would be no way to hack an individual Flex component using XSS.
I don't believe the code you write needs to be protected from cross site scripting. Your biggest fear is player vulnerabilities, which you don't have much control over.
None of this should be a reason not to validate user input.
The short answer is: the Flash player has a lot of features in place to prevent XSS attacks, but they're built in to the player itself, so there isn't any particular library you need to use. If you don't call any security-related APIs, and don't put config files on your server, then security-wise, you are already using the most restrictive settings available. (Assuming you also pay attention to how you make use of user input.)
More generally, APIs that have the potential to lead to XSS vulnerabilities are as a rule disabled in XSS situations unless you actively enable them. For example, if an HTML page on your site loads in a flash file from another site, and that flash content tries to, say, make javascript calls into your page, those calls will be blocked by default unless you allow them. Similarly, if flash content on your site loads in components from another site, those components will not be able to introspect into their parent unless you call APIs to allow them to. There are also various restrictions on what happens when another site tries to load in Flash content from your site without your having allowed it.
For all the details, I highly recommend this excellent overview:
Creating more secure SWF web applications
With all that said, since you also asked about sanitizing user inputs, it's worth noting that since AS3 has no equivalent of an eval command there is never any question of user input being executed as script. However, any user input that relates to content being loaded could be a vector of XSS attack. (For example, if you append a user-input string to a URL you then load, the user could cause your site to load in their malicious SWF.) But such a case is no different from a situation where you load in a benign 3rd-party SWF, and someone later replaces it with malicious content. Hence in context of Flash, protecting against XSS attacks is not so much about sanitizing user input as it is about making sure that externally loaded contents are not granted permission to run as if they were locally trusted.
And further, since it's often useful or necessary to relax the default restrictions if you want to do something interesting with 3rd-party content (like flash avatars, components, or even banner ads), in those situations it's important for the site admin to understand what they are allowing, and how to prevent the relaxed restrictions from exposing a vulnerability.