My website seems to producing a Cross Site Scripting (XSS) error. I would appreciate advice on how to cure it.
As ususal the key question is what have I just changed? The answer is added Facebook 'Like' buttons to my web pages. I am wondering if there is a conflict with the Google+1 code that I added about 2 months previously?
What can I do with my html (javascript) code to prevent this IE 8 / 9 Browser message, while keeping my Facebook and Google+1 buttons?
Related
This question already has answers here:
Chrome Extension won't appear by filtering in the Web Store, only by search
(2 answers)
Closed 6 years ago.
I have popular extension in Chrome Web Store in category Web Development.
For some reason it is missing in category view page, no matter how long I scroll the list down: https://chrome.google.com/webstore/category/ext/11-web-development
Any ideas of what is the reason and how to fix it? I hope someone from Chrome Web Store team can contact me
Chrome filters out extensions you already have installed from the "browse" view.
I can assure I can find your specific extension in that category.
You can check yourself from another browser profile (this carries over to Incognito, so it MUST be a profile without this extension).
Note, trying to contact CWS team through here is a poor idea. One can try the bugtracker for general issues, as at least some CWS issues are tracked there, and there's a (well-hidden) developer support form for CWS.
Recently I had a friend tell me that the navigation on my site was not working. After looking into the issue on his computer I realized that it was the Yahoo Toolbar (A 3rd Party Firefox Addon) that was somehow blocking the menu. I could see the menu but not access anything on the navigation menu. Once disabled the issue went away.
My question:
Are there methods or code that I can add to my site that will prevent (as much as possible) this kind of conflict as I obviously cannot control 3rd Party Add-Ons?
Basically are there any proactive ways to prevent any third party add-ons from interacting with my site? (Any browsers not just Firefox)
Notes:
The menu was a standard <ul> <li> CSS styled menu. No JS or anything fancy.
I use a hosted CMS and cannot use server side code. I am looking for solutions that involved only client side code. However, you can post code that uses server side if it can help prevent this issue for others who come across this question.
I'm working on a project for class. To create a website and a website for mobile users. The site is to recongize the type of device/browser accessing the page and send the appropiate form. So if I was to visit the site on IE8 it will direct me to the mainpage for IE8, if I was to access the site with a mobile device it will direct me to the mobile website main page automatically.
Also, I need to design the website for at least two different screen sizes.
I'm coding in HTML5, I do not know the type of server the site will be hosted on. The use of Javascript is extra credited. The project details are to "design a small mobile web site. The web site should be tested on one or more mobile devices. The iPod Touch device will be used as the base for testing."
I know how to do 8/10 of the requirements (except the two mentioned). I looked at W3C and didn't find anything.
Any help would be much appreciated. Thank you!
Do a Google for:
CSS Browser Detection
JavaScript Browser Detection
Also you should think twice about creating multiple sites - with basically the same content - or creating proper stylesheets that are referred from the same site.
Hope that get's you the other 2 requirements
NOTE: Since this is homework I won't post any links...
I suspect that ServerFault isn't the best place for this question...but aside from that, your question is a little vague. A google search for "designing a mobile website" turns up what looks to be several pages of relevant information. If you first try working with the information in those documents and then come back with specific questions (e.g., "I tried this and it behaved this way instead of the way I expected") you're apt to get better answers.
We're building a mobile-friendly site to work in tandem with our client's MOSS 2007 internet site. We need to be able to redirect users who hit the home page and are using a mobile device.
Our original intention was to add a custom control to the home page page layout that would detect the current user's device and redirect to the mobile site accordingly. We quickly realised that this would not work as we are using the Output Caching functionality provided by SharePoint/Asp.Net. This means that the detection code will only run for the first visitor to the home page until the cache expires.
Our next idea was to build a custom HTTP Module and process the detection there. However, we are finding that the Output Caching is not allowing that either. If the cache is set while a mobile device is visiting all browsers are subsequently redirected to the mobile site (until the cache expires).
If we turn off output caching it works just fine - but we cannot turn output caching off, especically for the home page. We did investigate Substitution (Donut) Caching but this is not working due to the fact we are filtering the Asp.Net response within another HTTP Module that tidies up the rendered HTML for XHTML compatiblity reasons. I've also experimented with the output cache profile by setting it to vary-by-header property to "User-Agent" but I am getting mixed results and am also concerned at the memory implications of caching multipel versions of pages (we already have memory issues now and then).
It's possible we could run the redirection code in JavaScript but then we risk not detecting a lot of devices that don't have JavaScript enabled. This is a government website so the usage of JavaScript has to abide by accessibility guidelines.
Does anyone have any other ideas as to how we can solve this issue. Has anyone done this before? Perhaps in a different way?
Hope you can help, thanks.
p.s. I have also asked this question on SharePoint.SE but wanted to get as many eyes on this as possible.
I would suggest you to try ISAPI filters
I've actually solved this one I think. I've pretty much followed this article here - http://msdn.microsoft.com/en-us/library/ms550239.aspx. We have updated the code in that article to build a cache key based on whether the current page is the home page, whether the current user is using a mobile device and whether or not a cookie exists forcing the user to the full site. I will probably write this up as a blog post. When I do I will update this answer providing a link.
I was thinking to add meta tag always in all the websites.
That will trigger google chorme frame to load for users who already installed. I can see the benefits but is there any concerns or facts that I should know before I do that?
Testing in google chrome is enough or testing in google chrome frame explicitly required?
Thanks
Note: please do not mention current know problems "print" and "download" issue. I'm sure those will get fixed soon :)
The only argument against chrome frame that I have seen so far is Microsoft's - "Google Chrome Frame running as a plugin has doubled the attach area for malware and malicious scripts."
Also, you may run into problems with frames. If you have chrome frame on your page and someone has that page iframed on their site you may run into some problems. More info:
http://groups.google.com/group/google-chrome-frame/browse_thread/thread/d5ffe442658bc60e/e6d7a4c1c179c931?lnk=gst&q=iframe
You should only need to test in Chrome Frame for (X)HTML, CSS, and JavaScript...basic stuff. If you are using AJAX (while trying not to break the back button), worried about caching, cookies (accessed via javascript), or other potentially browser-specific browser interactions I suggest testing on the IE+CF platform...at least until the CF team announces 100% interoperability between CF and IE.
Check out the CF Google group for more issues.
Are there any concerns or facts you should know? Yes: Not everyone has Google Chrome Frame installed.
You are adding a new user agent that you will need to test and debug against, without removing the need to test and debug the user experience for other browsers (notably plain IE by itself).
If you don't make the IE user experience equivalent to the Google Chrome experience, then you are alienating a significant percentage of users. Depending on your website and its expected users, the impact of this may range from undesirable to unacceptable. If you do make the user experience equivalent, then there is no point in adding the meta tag.