Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.
Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
https errors
When accessing my application over http: my app runs as expected.
However, when accessing it via https and IE8, I get this dialog:
Security Warning
Do you want to view only the webpage content that was delivered securely?
This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage.
[ Yes ] [ No ]
This occurs when accessing my vaadin app page.
Using View Source don't see any obvious problems on that page. I am still using alpha 1.
Is anyone else using https to access alpha 1 (or 2) applications? Any issues?
As mentioned in the previous post, when using https, I get this dialog when accessing my vaadin application with IE8:
Security Warning
Do you want to view only the webpage content that was delivered securely?
This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage.
[ Yes ] [ No ]
Independent of whether I select Yes or No, I then get this page:
I'm sorry, but your browser is not supported
The version (7.0) of the browser you are using is outdated and not supported.You should consider upgrading to a more up-to-date browser.
The most popular browsers are Chrome, Firefox, Internet Explorer, Opera and Safari.
Upgrading to the latest version of one of these will make the web safer, faster and better looking.If you can not upgrade your browser, please consider trying Chrome Frame.
Continue without updating (not recommended)
This appears to be a Vaadin page. I do not get this page when using http. And I am running IE8.
My About Internet Explorer page reports this:
Version: 8.0.7601.17514 64-bit Edition
Cipher Strength: 256-bit
Product ID: 00392-918-5000002-85279
Update Version: 0
This is with alpha 1.
One final error.
If I click on the "Continue without updating (not recommended)" link (from the previous message), I get the following javascript error (this is with alpha 1):
Window Internet Explorer
Errors on this webpage might cause it to work incorrectly
To see this message in the future, double-click the warning icon on the status bar.'JSON' is undefined vaadinBootstrap.js Line: 108 Code: 0 Char: 8 URI: https://.../VAADIN/vaadinBootstrap.js
I get this error only when running in https mode. But this is a different run time environment so there may be other variables at play.
But I can say with certainty that the browser and the war file are the same when using http and https, and I only get this error with https.
Oh hell, I had this error once in the past (in a JSF-project) ... It was nearly impossible to find out was going on. The IE will display the message as soon as any resource (Script, Image, CSS) gets loaded via HTTP instead of HTTPS. Even a 404 will do, if the (normally invisible) error-page is not delivered via HTTPS!
The second error looks like your IE is faking its user-agent (quirks mode). This happens if the Document-type in the delivered HTML-file doesn't have a specific format.
Here is the top of the (vaadin-generated) page:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
...Is there anyway for me to control the content of these lines? (I haven't searched the docs yet...)
Surely the fact that there are http: references is not causing this problem... (!!!)
This is line 108 of vaadinBootstrap.js where the JSON problem is:
var updatedConfig = JSON.parse(r.responseText);
In http mode, when it succeeds, r.responseText has what looks like a parseable JSON object.
In https mode, when it fails, r.responseText contains an entire web page:
"<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <meta http-equiv="X-UA-Compatible" content="chrome=1"/> <style type="text/css">html, body {height:100%;margin:0;}</style><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="/iwam2/VAADIN/themes/reindeer/favicon.ico" /><link rel="icon" type="image/vnd.microsoft.icon" href="/iwam2/VAADIN/themes/reindeer/favicon.ico" /><title>Vaadin 7</title> </head> <body scroll="auto" class="v-generated-body"> <iframe tabIndex="-1" id="__gwt_historyFrame" style="position:absolute;width:0;height:0;border:0;overflow:hidden;" src="javascript:false"></iframe><script type="text/javascript" src="/iwam2/VAADIN/vaadinBootstrap.js"></script> <script type="text/javascript"> //<![CDATA[ vaadin.setDefaults({ "debug": true, "widgetsetBase": "/iwam2/VAADIN/widgetsets/", "authErrMsg": { "message": "Take note of any unsaved data, and <u>click here<\/u> to continue.", "caption": "Authentication problem" }, "standalone": true, "appUri": "/iwam2/vdn", "comErrMsg": { "message": "Take note of any unsaved data, and <u>click here<\/u> to continue.", "caption": "Communication problem" } }); vaadin.initApplication("iwam2vdn-570455320",{ "versionInfo": { "vaadinVersion": "7.0.0.alpha1", "applicationVersion": "NONVERSIONED" }, "initPending": true, "widgetset": "com.vaadin.terminal.gwt.DefaultWidgetSet", "themeUri": "/iwam2/VAADIN/themes/reindeer", "rootId": 7 }); //]]> </script> <div id="iwam2vdn-570455320" class="v-app v-app-PositionManagementApplication"null><div class="v-app-loading"></div></div> <noscript>You have to enable javascript in your browser to use an application built with Vaadin.</noscript></body> </html> "
So it looks like there might be some server-side logic which is sending back the wrong thing (an entire web page instead of a parseable JSON object) when in https mode...
The url to which the XMLHttpRequest is posting seems to be protocol independent:
"/myapp/vdn/?browserDetails&rootId=8&sh=1050&sw=1680&cw=1680&ch=538&curdate=1338480819110&tzo=240&dstd=60&rtzo=300&dston=true&wn=myappvdn-570455320-0&1338480819110"
Does any one know if this works any better with Alpha 2?
About IE8 reporting that it is IE7: IE's have some special rules that it should run in compatibility mode (=IE7) under certain conditions. Check the developer tools to see which mode is on. You can turn it off in the browser settings but the default is 'on' so it is not really viable. There are some workarounds that you can search for in this forum, but check that this is truly the case before proceeding.
I don't think that this issue will be heavily affected by upgrading to alpha 2, but it still worth the shot. Alpha 2 is almost completely backwards compatible to alpha 1 so it shouldn't be a big hassle to test. Minimal changes to existing API, at least compared to 6 stable -> 7 alpha 1.
Well, the HTTP-References in the Doctype-section are usually not critical as the browser knows the Doctype-Declarations by heart and must not really call those URIs. Try to check if it is actually calling some HTTP-URI via Wireshark or Whistler. I have to admit that I had no luck with this tools, but they are worth a shot. I "fixed" the problem finally by reconfiguring the browser - good if one is working for a company with closed intranet ;).
Christopher Cobb: So it looks like there might be some server-side logic which is sending back the wrong thing (an entire web page instead of a parseable JSON object) when in https mode...
While I haven't looked at this in detail, my initial guess: some requests are made with HTTP and some with HTTPS and don't share the session (because of cookies or something on the server side). Therefore, the server thinks it is a completely separate and new session and serves the HTML.
Check what is requested using HTTP and what using HTTPS.
"'JSON' is undefined" from bootstrap.js indicates that your IE8 is running in IE7 mode. Built in JSON-parsing was added in IE8, and I guess IE pretends it doesn't support it when running in IE7-mode.