joe@: Is your NAS hosted at `http://10.0.42.10:5000`? `https` wouldn't match, for instance, and I vaguely recall Synology setting up self-signed certs for the device. Does the form submission redirect anywhere before landing at that final blocked URL?

Hi, the NAS in indeed hosted at: "http://10.0.42.10:5000". "https" is also available, but at "https://10.0.42.10:5001", not the address I'm using. It suffers the same sign-in issue as "http".

There does not appear to be any redirect which ends up at 'http://10.0.42.10:5000/webman/login.cgi?enable_syno_token=yes', at least nothing showing in the network tab in the dev tools. It does make some other network calls, but nothing seemingly related to the error.

I checked the HTML, the form component is:

<form id="login-form" class="x-plain-body x-plain-body-noheader x-plain-body-noborder x-form" method="POST" action="http://10.0.42.10:5000/webman/login.cgi?enable_syno_token=yes" target="login_iframe" style="width: 320px;">

That's strange. I put together a quick test at https://output.jsbin.com/zufaluyudo, which seems to work the way you'd expect it to work. I'll see if my synology at home exhibits the same behavior.

Is this only happening in Canary/Dev, or are you seeing it in stable?

Only on Canary, Stable works fine.

In case it helps the headers from the page load are:

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 23 Feb 2017 15:35:07 GMT
Content-Type: text/html; charset="UTF-8"
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Accept-Encoding
Cache-control: no-store
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Content-Security-Policy: base-uri 'self';  connect-src *; default-src 'self' 'unsafe-eval' data: blob: https://*.synology.com; font-src 'self' data:; form-action 'self'; frame-ancestors 'self' https://gofile.me http://gofile.me; frame-src 'self' data: blob: https://*.synology.com; img-src 'self' data: blob:; media-src 'self' data: about:;  report-uri webman/csp_report.cgi; script-src 'self' 'unsafe-eval' data: blob: https://*.synology.com; style-src 'self' 'unsafe-inline';

I can replicate this at home; it looks like the form submission is routed through an iframe opened to `about:blank`, and we're not doing the right thing with `'self'` in that context. It's a little hard to narrow down a minimal test case, as the page is pretty complicated.

Marking this as blocking M58 stable; I won't be able to dig in until I'm back in the office next week, but we'll get it fixed. Thanks for the report!

Actually, now that I think about it, this is almost certainly a bug in https://codereview.chromium.org/2699663002. Let me revert that and see if next week's canary works better.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4

commit 3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4
Author: mkwst <mkwst@chromium.org>
Date: Sat Feb 25 14:45:21 2017

Revert of CSP: 'self' should work inside sandboxes. (patchset #2 id:20001 of https://codereview.chromium.org/2699663002/ )

Reason for revert:
I suspect that this breaks Synology's UI, which submits a form through
an `about:blank` frame. Perhaps we're not persisting the fallback base
URL correctly?

BUG= 695058 

Original issue's description:
> CSP: 'self' should work inside sandboxes.
>
> We ought to be looking at the URL of a sandboxed resource when resolving
> the CSP source expression 'self'. Currently, we're looking at the origin
> of the resource, which is generally correct, but fails if the resource
> has been pushed into an opaque origin.
>
> This patch uses the fallback base URL of a document rather than its
> origin to do the comparison.
>
> BUG=692475
> R=jochen@chromium.org
> CC=andypaicu@chromium.org
>
> Review-Url: https://codereview.chromium.org/2699663002
> Cr-Commit-Position: refs/heads/master@{#451626}
> Committed: https://chromium.googlesource.com/chromium/src/+/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520

TBR=jochen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=692475

Review-Url: https://codereview.chromium.org/2711363004
Cr-Commit-Position: refs/heads/master@{#453091}

[delete] https://crrev.com/c5f5f6b86a87487c82e1967fcf523633f43e8f21/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/base-uri-self.html
[modify] https://crrev.com/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp
[modify] https://crrev.com/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4/third_party/WebKit/Source/core/frame/csp/SourceListDirectiveTest.cpp

Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome #58.0.3025.5 using the provided url in the comment #9.

Observed that on clicking on the submit button, there is a error in console 
"
Refused to send form data to 'https://output.jsbin.com/yay' because it violates the following Content Security Policy directive: "form-action 'self'".
"

Attaching the screen-cast for reference, could you please look into it and confirm whether this is the expected behavior or not ???
​

Deleted: Issue 695058.mp4 305 KB

	Issue 695058.mp4 305 KB View Download

joe@: Does the latest canary work for you?

Just tested with 58.0.3027.3, everything it working.

Great. Looks like that was a bad patch then. I'll close this out, and make sure not to break it again with the next attempt. :)

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

CL listed at #14 landed before M58 branch (3029). No merge is needed here.