I use an API to get Whois data of a domain
Sample response from API:
For domain 1:
registrant_contact":{
"full_name": "WHOISGUARD PROTECTED",
"company_name": "WHOISGUARD, INC.",
}
For domain 2:
"registrant_contact":{
"full_name": "Whois Privacy Protection Service by onamae.com",
"company_name": "Whois Privacy Protection Service by onamae.com",
}
registrant_contact.full_name may vary depending on the provider
Is there an easy or programmatic way to determine if domain has WHOIS privacy?
Thanks!
Whois Privacy is not a standard service. This is offered by multiple companies, including registrars themselves, with varying degree of service and features.
It can also be done on the registry level in some cases, specially in ccTLDs for individuals.
So, besides listing all specific text strings you can get back, I do not see a solution to your problem, except some heuristics (like the form of email addresses or postal addresses, etc.)
See this other answer for some heuristics: https://stackoverflow.com/a/25233555/6368697
Many domain registrars offer services called "domain privacy," or “private registration” that remove your personal contact information from the WHOIS record. Because of that, you cant get response for some domain. If you want to query the domain, you can use our whois tool http://www.yazilimdersi.info/araclar/whois-sorgulama. Our tool displaying domain information, domain owner, dates of domain with the remaining day.
Related
I'm familiar with mailto:// links; that's not what this is about.
This is more akin to Sniper Links, which are useful to reduce friction in the process of confirming a new user's email address. We've just sent the user an email, and we want to give them a one-click way to go find it.
Sniper Links, as described at the link above, are great for that, but they're limited, in that:
The user must have a web-based email service.
We must be able to determine the mapping between email hostname and email provider (e.g. "some.guy#gmail.com" should go to the Gmail interface).
Those are mostly solved problems. Most people these days do use web-based email, and many who instead choose to use dedicated apps can use a web-based client. This is not universal, of course.
Mapping between hostname and provider is sometimes trivial (like the #gmail.com example above), sometimes not (#somecompany.com -> Google Apps is less obvious). If it's not directly obvious from the hostname, an MX record lookup will reveal the truth in the case of Google Apps and a most of the other big names in corporate email hosting. Services like ZeroBounce offer APIs to do the lookup and translation for you, for a fee.
But there are users whose email addresses do not have web interfaces, or for whom the URL of the web interface is not easily determined. For these users, I'd like to be able to bring up their preferred email client (assuming the browser -- or the underlying OS -- knows what it is).
I know that a mailto:// link will launch the default email client (whether web or app) and start composing a new outgoing message.
From a web page, is there a way to launch the default email client without starting a new outgoing message? I'm assuming this would take the form of a URI scheme, but it could also be a JavaScript API call or something else entirely.
Bonuses:
Also cause it to navigate to the inbox
Navigate, search, or filter such that we're likely to find our specific message (based on sender, date, subject, mailbox, etc)
Navigate to the precise message we just sent
No, that is not possible. Browsers won't open Apps "without" a reason. This could also be a major security risk, if they would do.
During registration I am asking for username, email, and password. I am checking if the username and email is unique via the following end points
HEAD /auth/:email
HEAD /users/:username
Uniqueness of emails and usernames is split into auth and users resource because I thought when logging in I am asking for email so that should be in the auth and checking if the username is unique or not can go in users.
Login happens at the following endpoint
POST /auth/login
A new user is created at the following endpoint
POST /users
This is a stateless API and I am wondering if my routes look RESTful?
I am wondering if my routes look RESTful?
REST doesn't care what spelling conventions you use for your resource identifiers, so long as they conform to the production rules described in RFC 3986.
See, for instance: Tilkov 2014.
Instead, you should choose your identifier spelling conventions to make things easier for your human beings: what spellings are easy to document? what spellings are easy to recognize in the access logs? and so on.
You might be better off with a single resource that reports the status of the email address and username together, rather than using two different reports to do that.
Similarly, using HEAD requests is a bit weird; you are apparently using metadata in the transfer of documents over a network domain to communicate your business semantics, which (a) is what the documents are for and (b) is an example of "accidental complexity" -- I won't go so far as to guarantee problems down the road, but you are certainly inviting them, and it's not obvious that the current benefits outweigh that risk.
We have a backend (RESTful) service for websites that depends upon uniquely identifying the same user across multiple, unrelated websites. We have been using email address as the unique identifier, but email address is not always used by all websites, especially when OpenID authentication is by those websites.
So, does OpenID provide a unique identifier that would be the same across multiple Relying Parties (if the user authenticates with the same OpenID)?
If so, what would one instruct a series of independent website to provide us as a user identifier for each of their users if the goal was that multiple, unrelated websites provide the same identifier when they each have the same OpenID user?
Also, a goal is to make this as easy as possible for developers that will consume our APIs. So, if you know of any good API documentation that has already solved this, links to that would be very helpful.
Without knowing anything about your web service or what language its written in, I'm not certain how helpful my answer will be as it will be fairly general and less technical.
OpenID providers responding to an identification/authorization request will respond with a "Claimed ID" and an "Identity" as well any "attribute exchanges" requested. The attribute exchange information can be things such as email/username/language/realname/etc that may be what you are looking for.
Google (as an OpenID provider) supports querying a decent number attribute exchange information, and provides a list in their documentation:
https://developers.google.com/accounts/docs/OpenID#Parameters
The OpenID Identity should be unique to a user, but may not cross-identify them to different websites even when issued from the same provider. (It can be a directed id unique to the RP it was issued to).
See more on this here:
is openid.claimed_id static?
With all of this said, it is perfectly reasonable for you, as the designer of the API, to define that certain information (i.e. an email address) is required to consume the webservice. And then leave it to the parties that wish to use your webservice to somehow gain that information (directly asking a user, or through attribute exchange, etc).
For more information on OpenID I would look at their website, particularly the specifications and libraries:
http://openid.net/specs/openid-authentication-2_0.html
http://openid.net/developers/libraries/
Libraries with some good documentation to use as a starting point include:
JOpenID (Java): http://code.google.com/p/jopenid/wiki/QuickStart
LightOpenID (PHP): http://code.google.com/p/lightopenid/w/list
Implementing the OpenID authentication directly would not be applicable for a backend webservice since the end user has no involvement (i.e. could not supply credentials).
To meet your requirement of identifying the same user across various 3rd party websites you may need to become an OpenID provider. And then provide further API to allow functionality on 3rd party websites for users to link into their OpenID profile you manage.
Without being the actual provider of the identity... Sharing the OpenID identity with a 3rd party may be a potential security/privacy concern or in the very least against the specs of OpenID (which describes the exchange as a a shared secret between the RP and OP). Though it may be beyond the scope of what you wanted to do, being the OpenID provider would at least remove many of the privacy issues since the users would have to opt-in explicitly.
I'm not aware of any APIs that handle uniquely identifying users across multiple 3rd party websites without direct user interaction. Most webservices that I have written required either direct user credentials be supplied (for which the user was aware), or had to only identify a user as unique to a particular client. In the later case user authentication is not always necessary, the client could do a blanket authentication and then provide its own unique ID to track users, letting the the webservice be blind to what actually constitutes a user. Your requirements do not appear to fit into these common scenarios unfortunately.
One final thing to consider as you design your API...
Providing uniquely identifiable information (i.e. an email address) to a 3rd party may raise some eyebrows in the internet privacy ring. Especially if there is any financial gain to be had from the exchange (advertisments/directly-paying/etc) or if the use of the information is unknown/insecure or otherwise unwelcome.
http://www.ehow.com/about_5332990_legal-sell-email-list.html
http://www.aclu.org/technology-and-liberty/internet-privacy
You may want to ensure that your target clients (the consumers of your webservice) have the right jargon in their terms or can provide sufficient power to their users that allow them to opt-out of being submitted into your service. And make it clear what you are doing with the information...
Issues like that can be something that holds up acceptance of your API, so it is worth considering.
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.
We are in the early design stages of a major rewrite of our product. Right now our customers are mostly businesses. We manage accounts. User names for an account are each on their own namespace but it means that we can't move assets between servers.
We want to move to a single namespace. But that brings the problem of unique user names.
So what's the best idea?
Email address (w/verification) ?
Unique alpha-numeric string ("johnsmith9234")?
Should we look at OpenID?
EMAIL ADDRESS
Rational
Users don't change emails very often
Removes the step of asking for username and email address, which you'll need anyway
Users don't often forget their email address (see number one)
Email will be unique unless the user already registered for the site, in which case forward them to a forgot your password screen
Almost everyone is using email as the primary login for access to a website, this means the rate of adoption shouldn't be affected by the fact that you're asking for an email address
Update
After registration, be sure to ask the user to create some kind of username, don't litter a public site with their email address! Also, another benefit of using an email address as a login: you won't need any other information (like password / password confirm), just send them a temp password through the mail, or forgo passwords altogether and send them a one-use URL to their email address every time they'd like to login (see: mugshot.org)
OpenID is very slick, and something you should seriously consider as it basically removes the requirement to save local usernames and passwords and worry about authentication.
A lot of sites nowadays are using both OpenID and their own, giving users the option.
If you do decide to roll your own, I'd recommend using the email address. Be careful, though, if you are creating something that groups users by an account (say, a company that has several users). In this case, the email address might be used more than once (if they do work for more than one company, for example), and you should allow that.
HTH!
I like OpenID, but I'd still go with the email address, unless your user community is very technically savvy. It's still much easier for most people to understand and remember.
If you use an email address for ID, don't require that it be verified. I learned the hard way about this when one day suddenly the number of signups at my site drastically decreased. It turns out that the entire range of IP addresses including my site's IP was blacklisted. It took a long time to resolve it. In other cases, I have seen Gmail marking very legitimate emails as spam, and that can cause trouble too.
It's good to verify the email address, but don't make it block signups.
Right now our customers are mostly businesses.
People seem to be missing that line. If it's for a business, requiring them to login via OpenID really isn't very practical. They'd either have to use an external OpenID provider, or their poor tech people would have to setup and configure a company OpenID.
If this were "should StackOverflow require OpenID for login" or "Should my blog-comment-system allow you to identify yourself via OpenID", my answer would be "absolutely!", but in this case, I don't think OpenID would be a good fit.
If most of your customers are mostly businesses then I think that using anything other than email creates problems for your customers. Most people are comfortable with email address login and since they are a business customer will likely want to use their work email rather than a personal account. OpenID creates a situation where there is a third party involved and many businesses don't like a third party involved.
I think that OpenID is definitely worth looking at. Besides giving you a framework in which to provide a unified id for customers, it can also provide large businesses with the ability to manage their own logins and provide a common login across all products that they use, including your own. This isn't that large of a benefit now when OpenId is still relatively rare, but as more products begin to use it, I suspect that the ability to use a common company OpenId login for each employee could become a good selling point.
Since you're mostly catering to businesses, I don't think that it's all that unreasonable to offer to host the OpenId accounts yourself. I just think that the extra flexibility will benefit your customers.
If you are looking at OpenID you should check out http://eaut.org/ and http://emailtoid.net. Basically you can accept email addresses for a login and behind the scenes translate them to OpenID without the user having to know anything. Its pretty slick stuff...
I personally would say Email w/ Verification, OpenId is a great idea but I find that finding a provider that your already with is a pain, I only had an openId for here cause just 2 days before beta I decided to start a blog on blogspot. But everyone on the internet has an email address, especially when dealing with businesses, people aren't very opt to using there personal blog or whatnot for a business login.
OpenID seems to be a very good alternative to writing your own user management/authentication piece. I'm seeing more and more sites using OpenID these days, so the barrier to entry for your users should be relatively low.