Cant get to admin panel

Hello, I am setting up my “personal cloud” on a one domain with this setup, using Digital Ocean -
(www.) - home page with blog or someting - MyCloud or SeaFile droplet - Mail-In-a-Box droplet, using for emails
First I set the box stuff, using DigitalOcean DNS and that works. Then I created mail droplet, named is, added domain to this droplet, used mail-in-a-box setup and it went all ok. But now when I open IP/admin, I am getting top menu that I am unable to use and page shows the defaul domain webpage

this is a mail-in-a-box
take control of your email at

Any help on that, please? I have no idea what to set up next, maybe it is something with the DNS.

EDIT: I just found out that this happens only on a PC, when opening page on iPhone, it works…

Have you tried going to?:

Decentraleyes was blocking js files :unamused:

I ran into the same issue with the admin panel and the decentraleyes firefox addon and had to whitelist my mailserver domain in the addon preferences. This is a real shame, as part of the reason I’m using mailinabox is to reduce my contact with google and others.

It looks like decentraleyes is adding a default whitellist for known sites where the proxying isn’t working, but that doesn’t help with mailinabox.

Pull requests are welcome. Build the thing you want to see in the world.

I’ve taken a look, but don’t yet know why things ain’t working.

I dumped out the requests using the LiveHTTPHeaders firefox addon

Without decentraleyes: HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/2.0 200 OK

With decentraleyes installed and running: HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK

The only difference is the request for is blocked when decentraleyes is turned on. The docs/issues at suggest that isn’t currently being intercepted, so that’s why those requests are made in both cases.

It’s not immediately obvious why the interception is failing for jquery/1.11.3/jquery.min.js as I found mention of that version in the decentraleyes repo. I’ll look further.

It appears that decentraleyes behaves differently for <script> tags with an integrity element.

The script that isn’t being loaded is embedded as follows:

<script src="" integrity="sha256-rsPUGdUPBXgalvIj4YKJrrUlmLXbOb6Cp7cdxn1qeUc=" crossorigin="anonymous"></script> has the following:

if (node.hasAttribute('crossorigin') || node.hasAttribute('integrity')) {   
    // Add corresponding origin domain to the list of tainted domains.
    storage.taintedDomains[] = true;

I’m not sure how that changes the behaviour though.

I looked at the Firefox developer web console while loading /admin with decentraleyes turned on. There were the three errors/warnings below.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at (Reason: CORS header 'Access-Control-Allow-Origin' missing). :: <unknown>

None of the "sha256" hashes in the integrity attribute match the content of the subresource. :: admin

Error: Bootstrap's JavaScript requires jQuery :: bootstrap.min.js:6:37

This led me to Breaks report-uri analyse tools · Issue #17 · Synzvato/decentraleyes · GitHub (and a couple of other linked issues)

The decentraleyes developer sez:

But should not the hashes be equal if the file is exactly the same […].

That’s a very good observation! The injected code is, of course,
fully identical. Bundled files have been stripped of things like source
mapping comments, because the actual mapping files are not bundled to
save space. Also, by default, Decentraleyes adds comments to injected
files to signal local delivery.

A tool to ensure resource integrity is included in the add-on, and is
also used by reviewers at Mozilla to make sure the actual code is
unaltered. So that’s why regular file fingerprints often don’t match.

The reason the other attribute crossorigin causes
issues, is because it demands that the responses contain headers that
state cross-origin requests are allowed. Decentraleyes currently
redirects requests to data URIs. That particular protocol has nothing to do with HTTP, so chaos ensues.

That’s the problem in a nutshell. Any ideas or suggestions are highly welcome!

So, TL;DR, the combination of the crossorigin and integrity attributes of the <script> tags in the /admin page aren’t currently supported by decentraleyes, so you need to whitelist your email domain in the addon until the addon is fixed.

UPDATE 2016-05-09: Decentraleyes v1.3.5, which was released recently appears to fix the issues with the admin pages of MiaB. I removed my mailserver from the Decentraleyes whitelist, and everything worked as expected.

The Decentraleyes release notes include:

Enhanced: Improved CDN-mappings.
The add-on now supports a greater amount of Google Hosted Libraries
shorthand mappings. This effectively means that it’s now able to detect
even more injection opportunities, and can prevent an even higher amount
of requests to this particular network.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.