There are couple of ways for a website to know where a user comes from, like search engine, social platforms, email newsletter, etc. Great way to monitor traffic and assess campaigns.
If a website sends regular newsletter, it also gives the option of managing subscriptions. One clicks on the link and can choose to set the frequency or entirely stop letters altogether among other settings.
But what if, for eg, A sends the newsletter to her friend B, B somehow decides to stop receiving any mails from A decides to unsubscribe! But effectively A gets screwed.
So is there anyway for a website to know that the request to get unsubscribed actually came from another email account and not its original subscriber?
I am not aware if Mailchimp or other services know how to handle this, so pls guide me so.
Of course there are couple of other ways to authenticate like to login and then change but I have seen many newsletter straight away unsubscribing without even confirming the request. I am not aware if they do some sort of check before doing that. But this can also be used to tell something to the website about its letter, like A forwarded to B but B did not like.
Thanks.
The only way you can expect to be able to identify a user in this way is to see of they have a cookie previously issued with a session, that you can associate with the user's account, that was authenticated by a login on your site.
Alternately, you can ask users to email the word "unsubscribe" in a message from the original account instead of depending on a link.
Related
In developing our docusign application, we need to use real emails addresses (to test the addressing logic, etc.) but we do not want those users to get all the development envelopes. In our own code, we handle this using mailtrap.io, a custom SMTP service that traps emails and sends them all to a common inbox that developers can review. Is there a way to do something similar in your docusign developer account, where you would be using real email addresses, but they would not actually go the intended user.
thanks,
~Bill
Thanks for any help
No, you cannot. The emails are sent from DocuSign.
If you want to test the real thing, completely real, then it also includes emails being sent.
If you are ok making any change, so it's not 100% like the real thing, I would suggest to take your email address and change the domain (mailinator.com or your own internal domain) this is a change, yes, but also changing the SMTP server is a change, so in either case - you are not doing 100% what the real app will do.
The emails can also be suppressed (by changing account settings in DocuSign), but again, that won't test the real thing if that's what you need.
Although I know a lot of email clients will pre-fetch or otherwise cache images. I am unaware of any that pre-fetch regular links like some link
Is this a practice done by some emails? If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.
This effectively makes all one-time use links like login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't work for some of them and it appeared that BingPreview/1.0b is hitting the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem: https://www.drupal.org/node/2828034
Although I know a lot of email clients will pre-fetch or otherwise cache images.
That is not even a given already.
Many email clients – be they web-based, or standalone applications – have privacy controls that prevent images from being automatically loaded, to prevent tracking of who read a (specific) email.
On the other hand, there’s clients like f.e. gmail’s web interface, that tries to establish the standard of downloading all referenced external images, presumably to mitigate/invalidate such attempts at user tracking – if a large majority of gmail users have those images downloaded automatically, whether they actually opened the email or not, the data that can be gained for analytical purposes becomes watered down.
I am unaware of any that pre-fetch regular links like some link
Let’s stay on gmail for example purposes, but others will behave similarly: Since Google is always interested in “what’s out there on the web”, it is highly likely that their crawlers will follow that link to see what it contains/leads to – for their own indexing purposes.
If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
rel=no-follow concerns ranking rather than crawling, and a no-index (either in robots.txt or via meta element/rel attribute) also won’t keep nosy bots from at least requesting the URL.
Plus, other clients involved – such as a firewall/anti-virus/anti-madware – might also request it for analytical purposes without any user actively triggering it.
If you want to be (relatively) sure that any action is triggered only by a (specific) human user, then use URLs in emails or other kind of messages over the internet only to lead them to a website where they confirm an action to be taken via a form, using method=POST; whether some kind of authentication or CSRF protection might also be needed, might go a little beyond the context of this question.
All Common email clients do not have crawlers to search or pre-build <a> tag related documents if that is what you're asking, as trying to pre-build and cache a web location could be an immense task if the page is dynamic or of large enough size.
Images are stored locally to reduce load time of the email which is a convenience factor and network load reduction, but when you open an email hyperlink it will load it in your web browser rather than email client.
I just ran a test using analytics to report any server traffic, and an email containing just
linktomysite
did not throw any resulting crawls to the site from outlook07, outlook10, thunderbird, or apple mail(yosemite). You could try using a wireshark scan to check for network traffic from the client to specific outgoing IP's if you're really interested
You won't find any native email clients that do that, but you could come across some "web accelerators" that, when using a web-based email, could try to pre-fetch links. I've never seen anything to prevent it.
Links (GETs) aren't supposed to "do" anything, only a POST is. For example, your "unsubscribe me" link in your email should not directly unsubscribe th subscriber. It should "GET" a page the subscriber can then post from.
W3 does a good job of how you should expect a GET to work (caching, etc.)
http://www.w3schools.com/tags/ref_httpmethods.asp
I have been asked to add some email addresses to individuals personal portfolio galleries on a site I designed.
There is already a very visible email form that customers can use, but it only goes to one address. Then the master email recipient has to forward the email to the intended recipient. When the business started there was only one master recipient. But now there are 5 or 6 artists and the shop is growing.
My first thought was to put href="mailto:" links on everyone's personal page. This would not be convenient for customers without a configured email client, but copy and paste would be fine. Also, The customer is worried about spam, but I think email filters would be more effective then some obfuscation technique.
Then I read this which says using mailto "screams 'this web site has been developed by a beginner.'I don't really agree. The author advocates using server side forms. I already have made a PHP form and could easily add a drop down of recipients (maybe not so easy, but it could be done) or have the recipient field auto fill on a certain persons page.
My real question(s) is/are threefold:
Does using mailto demonstrate some kind of beginners ignorance?
What would be the best practice to easily allow an average website user to email an individual from a small group?
And is email obfuscation critical?
BTW I've already ready a found a little data that suggests that obfuscation is (sort of effective), but the article seems dated.
Disadvantages of using mailto: links:
Show the recipients email address (unless obfuscation is used)
Users need to have a working email client installed on their computer. Nowadays more and more users only use a web based email client, which won't work with mailto: links.
Personally I'd go with a server created contact form.
Does using mailto demonstrate some kind of beginners ignorance?
Not at all, mailto: and a mail icon is state of the art if you display a mail address. It's a UX and accessibility fail if you declare it as regular text. Especially for mobile users.
Using a contact form instead provides some benefits, but may also make your page vulnerable to mail spamming or even getting hacked if you don't watch out and update regularly.
What would be the best practice to easily allow an average website user to email an individual from a small group?
That's hard to say, it depends on the design and use case. I would recommend using a simple AJAX contact form with as few fields as possible ("Ask me a question:") and a ReCaptcha v3, but a simple mailto: link with a predefined subject is also fine.
And is email obfuscation critical?
I had to research this today and it seems to still be necessary. Most bots search for common patterns in the page source and don't use JavaScript.
You could add the href and insert the # symbol using JS after the DOMContentLoaded event: <a class="uncrypt">user???example.com</a>. But this is just one way of many.
Bots that use JS could still get the address, but that's hard to avoid anyway and I personally think it's more important to create a good UX for all users than making your page bullet proof to spammers.
But you don't have to protect generic addresses (like info#<domain>) as spammers will try those anyway.
Follow the leaders
Having simply an email link on a site isn't an especially good indicator of a high quality site. Quite simply, this is because high powered sites, sites with millions of users per day (microsoft.com, stackoverflow.com), or multinational corporations like Amazon do not do that. If they did, that persons email would probably be buried in a day.
Pros of the mailto: link:
Simple
Trivially understandable
Cons:
Exposes contact information directly
Not flexible
Not what the pros do
Email mailto links cause bad user experience *
Here are a few additional approaches that provide more professionalism:
- If anonymity is a goal, a generic contact form. No user is exposed, could be 10 it people ready to respond to it, could be 1, could be 100. Submit to a back-end, forward to 10 people on the back-end if you like.
- If you want to put a face to the contact, or you want to allow users to contact specific individuals, use user profiles with avatars of their faces, clicking a button also displays a contact form, perhaps in a modal.
When you click a link and your email spins all 8 of your cpus as you wait for the world to end, you can see how the user experience suffers with having to open an unrelated email client
I am relatively new to web development, and I was hoping I could get some pointers about the feasibility of a feature I would like to implement. Is it possible to have a url link that you can click on, that can contain login credentials for the website it is linking to, so as to bypass that websites login screen?
In other words, can I make a link from my website to facebook, that would allow me to login right in to my facebook, from any computer? Meaning, if I don't have cookies to store my login info in, is it possible to login still?
This is just a conceptual question, so any help would be appreciated! Thanks!
One reason why this is generally avoided, is because web servers often store the query string parameters in the access logs. And normally, you wouldn't want files on your server with a long list of usernames and passwords in clear text.
In addition, a query string containing a username and password could be used with a dictionary attack to guess valid login credentials.
Apart from those issues, as long as the request is made via HTTPS, it would have been safe during the transit.
It is possible to pass parameters in the URL through a GET request on the server, but one has to understand that the request would likely be made in clear text and thus isn't likely to be secure. There was a time where I did have to program a "silent" log-in using tokens, so it can be done in enterprise applications.
You used to be able to do this, but most browsers don't allow it anymore. You would never be able to do this using facebook only something that uses browser auth (the browser pops up a username/pass dialog)
it was like this:
http://username:pass#myprotectedresource.com
What you might be able to do is whip up some javascript in a link that posts your username and password to the login page of facebook. Not sure if it will work because you might need to scrape the cookie/hidden fields from the login page itself.
It is possible for the site to block you on account of no cookies, or invalid nonce or wrong HTTP referrer, but it may work if their security is low.
While it is possible, it is up to the site (in this case Facebook) to accept these values in the query string. There are some security issues to consider certainly, and isn't done generally.
Though, there are different options out there for single sign on. This web site uses OpenID for that.
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.