Need to login to my Netdata cloud account but don’t get any email delivered.
I have checked junk folder, nothing there.
I have checked sending email to the given address, that does come through right away, so the email is working ok.
Just the important one with the login link doesn’t come through. Can you please have a look?
Hello Jurgen,
Thank you for contacting us about this and apologies for any inconvenience caused.
Could you please send me a private message with the e-mail you used so that I check about that?
Kind regards,
Christos
Hello Jurgen,
Thank you very much for providing the required details. Our email service reports that the e-mail was successfully delivered to your email provider twice today, and also that in the previous days emails were successfully delivered and opened.
Could you please check again later to see if the problem persists or check with your e-mail provider in case the e-mails are filtered for any reason?
Hi @chrikar
well, I’m getting more and more frustrated with this whole authentication process on NetData cloud. It is so terribly broken!!!
Already a couple of years ago, an issue has been opened that this process with the link to login should be replaced and NetData confirmed that they are working on a proper process. Still, nothing has changed.
Now, with this current issue, I can only get the system to accept your email when disabling really every (!!!) filter on the mail server. Now, I got one login mail through and got shocked: the link is not even https, it’s just http. Boy, can it get any worse?
So I thought, let’s change authentication and use Google instead of email. Because your platform doesn’t allow changing of authentication method, I’ve invited myself to the account with a different email address. Had to disable all filters there as well and received the invitation. Authenticated with Google and got in. But what’s that??? That new account is not linked to the one that invited me, is it?
Well, what can we do next?
And now, to make things even “nicer”, that new account, which I created but which didn’t get linked to the inviting account, now receives newsletters. I have certainly not agreed to receive any, so why are you doing that?
@jurgenhaas would you mind dm’ing me or emailing me (andrewmaguire@netdata.cloud) the new email address you made that is now getting marketing material? I just want to try and trace all the events to see exactly why or where/how you must have got opted in.
That new account is not linked to the one that invited me, is it?
The new account is not linked to the account that invited you. The invite is to add an existing (or new if not exists) account/email to the Space. So it should be that if you invited the new gmail as admin on the Space it should just be like a new user who is also admin on that space. We don’t really have any notion of directly linking accounts or teams etc as of yet.
Hi @andrewm4894 thanks for following up on this. I’ll send you the email addresses as a DM shortly, but want to describe the scenario here:
That created a new account, but that new account has no access to anything in the originally inviting account from mail1@example.com
So, because the email authentication is really painfull, I’d like to change that to GitHub auth and need your advise on how to achieve that. If we get the process with the invitation to work, that should be fine, but I need to transfer ownership to that second account then. If there is a better way to get there, should be fine too. But I just can’t continue with it as it stands now. Hope you can help me out of this.
i can see how maybe mail2 → mail3 via github might have taken you off the happy path here maybe. @chrikar any idea if maybe this could be some sort of edge case bug or unexpected (on our part) behaviour we need to try handle better?
@jurgenhaas my guess would be if you had of invited mail3@example.com instead of mail2 all would have been fine - is that possible for you to do?
i could see arguments that if you invite mail2 and github auths actually its mail3 then maybe that should not be allowed as github has not in fact confirmed mail2, it confimed mail3 but i guess indirectly validated mail2 by being able to do that. This not my area of expertise at all so just thinking out loud (am sure there is a standard practice/answer here i’d just need to look up).
if possible, to unblock you, can you just invite mail3 and auth with that via github? (or maybe some reason that not possible/feasible?)
p.s. i’ve asked internally the marketing team about the marketing emails and if the receiving of the marekting emails is covered sufficiently by Terms of Use - Netdata . I have no idea but can see your point about them being unexpected even if it was explicitly mentioned in the terms (which I’m unsure on myself). I think a checkbox as part of the terms accepting could make this clearer and give people the options to opt out. Not sure if my understanding on the expected behaviour (on our end) is fully correct but just wanted to share that with you.
@andrewm4894 I’ve now also invited mail3 and the second user is now linked to my original account too.
But this is certainly NOT like authentication by a third party is supposed to be working. They never ever verfiy any email addresses. They authenticate a user session and hand that over to the application - NetData in this case - with an access token that comes with the guarantee, that the user who logged in is the one they pretend to be.
If the process depends on email addresses being compared, then the auth process is broken even more seriously.
Also, what we seem to have lost: the invitation link that’s being sent is http and not https, this is just unacceptable.
Marketing email can only be sent out according to European privacy regulations - i.e. GDPR - if you received the confirmation by the recipient upfront. So, it’s opt-in and not opt-out.
All in all, you’re really developing an amazing product and surounding services. But the authentication process is a real concern and other processes of the business are just way off. I hope you manage to catch up with the product’s quality level with the others too, because that could otherwise destroy the rest of it easioly.
I’m having the same problem, I can’t log into my account, email isn’t being delivered
Thank you
I completely agree with you. Moreover, the email may become available to a third party. I think it’s safer to login / pass + two-factor authentication. All the same, this is very serious data. Thank you
100% noted - this is some great clear feedback we totally need to take on board.
auth has been for sure an area where some people hate the google/github option and just want old school email/pwd, i think we need to just expand more options/approaches for sure. 2fa defo interesting too (obvious no brainer).
@simonflex were you able to get in at all or still struggling? (if not can you dm me the email so i can ask someone from backend on our side to dig into it)
@andrewm4894 let me please clarify things:
some people hate the google/github option
This has nothing to do with hate. It is a matter of distrust. And at least here in Europe we should take privacy concerns really serious?
just want old school email/pwd
How can you call this “old school”. TBH, I do hate emails and I’m more than happy to authenticate with a username and password with TFA, instead of email.
But to have an authentication process where a non-https links is being sent around, no matter if this is for login or invitation of other accounts, is such a mess, that you are about to ruin all of the reputation to earnd with all your hard work, that even 2 years after raising this issue the first time it’s still not even addressed, is something I can’t believe.
I’m sure you can “hear” my anger. You know why? I’m a huge fan of your product and I spent many hours in interviews with your technical and marketing people over the years. But I’m losing confidence. If you’re getting things that wrong in the authentication process, how is it possible that the agent runnding on my hardware is somehow secure???
A lot of points to address here:
I just logged in via email to verify that the link is http. I couldn’t, the link I see is https. Can you help us reproduce it? I suggest you create a bug report in netdata/netdata-cloud with the precise steps that lead to an http link, but you can do it here too, if it’s too much trouble.
The email login method itself isn’t a Netdata innovation. It’s what Slack has used for years. Just like Slack, the links we sent expire after a short while. Adding 2FA on top of it is a valid suggestion. We will check it when we migrate to a new authentication system.
The reason we haven’t added new authentication methods or made other improvements there is that we have decided we need to move a third party authentication provider. Last year we did a PoC with Google Identity Platform, but we’re migrating to AWS, so we postponed that project to go with the AWS equivalent.
Every new user is opting in to our privacy policy and terms of use when they log in. A user is identified only via their email, so all preferences and access rights including the opt-in itself are linked to the email address. We have no way to link two email addresses to the same person, the email address is the only thing that identifies the person. This should make evident the reason why you started to receive marketing emails again. All our marketing links include unsubscribe links. The process is fully compliant with GDPR.
We’re not clear on how authentication works in our login screen and in our documentation. You figured out the hard way that each email is its own user and probably understand by now that any user (i.e. email address) can have all 3 authentication methods active at the same time. We will address this deficiency with an FAQ and a link from the authentication screen to that.
Your case is one of 3 different email addresses, one for each authentication method. As described above, email is our unique identifier. We have no established process to provide access to that account via a different authentication method that is linked with a different email address. It may be technically feasible to move rights from email 1 to email 2, but it will be a manual process. I believe a private communication with @chrikar above will resolve this. Note that this isn’t a particularly unusual limitation. There are several applications that don’t allow “transfer of ownership” or “email address change”. I suggest you add the feature you’d prefer to see in the suggestions area in this forum and allow other users to vote on it too. In any case, it’s not something we can plan until we have moved to the AWS authentication provider service (probably Q3 2022).
I hope I haven’t missed anything. We really appreciate the time you devoted to this @jurgenhaas and it’s obvious that you do it because you care.
I just logged in via email to verify that the link is http. I couldn’t, the link I see is https. Can you help us reproduce it? I suggest you create a bug report in netdata/netdata-cloud with the precise steps that lead to an http link, but you can do it here too, if it’s too much trouble.
Well, check the link which is sent by email, it looks like this: http://url9538.netdata.cloud/ls/click?upn=..... which is clearly http and not https. If you click on that it will open in the browser which immediately redirects you to an https URL, but that’s might be too late already.
The email login method itself isn’t a Netdata innovation. It’s what Slack has used for years.
If only Slack were a reputable service. It’s well known that they are all but respecting privacy.
The reason we haven’t added new authentication methods … Google … AWS …
Well, I just hope any upcoming solution is going to allow me using your services without having to use any of these guys.
Every new user is opting in to our privacy policy and terms of use when they log in.
It might well be that you T&Cs say something like automatic sign-in. Just that this is NOT compliant with GDPR. It clearly states that users have to actively opt-in with the checkbox being disabled by default.
We’re not clear on how authentication works in our login screen and in our documentation. You figured out the hard way that each email is its own user and probably understand by now that any user (i.e. email address) can have all 3 authentication methods active at the same time. We will address this deficiency with an FAQ and a link from the authentication screen to that.
But that’s not how authentication should ever work. An FAQ doesn’t heal that. Let’s say, when I invite a new user, they get sent a link which is unique to that invitation. Regardless how they authenticate, the invitation should be bound to the identifier in that invitation and not to any email address.
Note that this isn’t a particularly unusual limitation. There are several applications that don’t allow “transfer of ownership” or “email address change”.
Maybe some of the providers who have no idea how users have to use online services may still have procedures or limitations like that.
In any case, it’s not something we can plan until we have moved to the AWS authentication provider service
OMG, if that’s coming through, that will be the end of using this service.
Yes, I do care a lot. User account management is a well-established art, and it’s critical. Services who are not willing to use open standards, instead lock their users into some third-party infrastructure like AWS, should be dying as quickly as possible. Having open standards keeps things independent and accepts that users need choice. As for authentication there is LDAP, OAuth, CAS and so many others - easy to implement and maintain by yourselves. Not doing so is like handling software security like an afterthought.
Hello
Here is a little digression from the topic.
It is impossible to get into the account in a priori.
Email link not coming. There is no understanding of what the problem is, service or problems with mail routing.
Thank
@Christopher_Akritid1 You can not focus on the mail to enter. It can be anything, for example, a problem with mail forwarding and so on. There may be quite a few if you don’t know.
@jurgenhaas I fully agree with you on all points.
Access via links from the mail is complete nonsense.
Netdata position is confidentiality and security, but authification puts this in great doubt.
Thank you
The authentication method is about security, not privacy. Our privacy policy is very clear and GDPR compliant.
We will add a traditional username/password login method
This is precisely the way it’s supposed to be. If it’s not, it’s a bug. Will check internally.
We appreciate this feedback. We will take your suggestion into consideration, when we migrate to the new authentication provider.
I see your point about open standards and we’re big fans of them. What we’re not willing to do is reinvent the wheel for authentication. We will take your input into serious consideration and reconsider the AWS thing.
To help you with this I will need the email address you use. Please DM me or send it to chris@netdata.cloud
@Christopher_Akritidi Hello. Thank you. Problem solved. Got access to cloud.netdata Now the link comes to the mail.
Best regards