In our website we want to launch country specific domains. so which one is preferred over another like add-on, parked domains or anything that i don't know.
our requirements is quite simple we want to publish country specific domain but the contents are mostly same except some price changes and unique features and/or languages for particular countries. so to take advantage of maintainability we want to use code from single directory in whatever choice we select.
right now we are in impression that we should go with add-on domain but i think we can also accomplish our requirements by using parked domains and detecting from which country domain the user is came from and render content accordingly.
Why not just go with a sub-folder like domain.com/us (for US for example) or maybe even a subdomain (us.domain.com [again, for the US version]) as explained here? Much better and cheaper alternative IMO than buying dozens of country-specific TLDs...
Related
Suppose you wanna analyze your access log files in order to check users activities. One common way is to assume that a same IP address corresponds to a same user.
However, several internet providers use CGNAT. Which, briefly, allows multiple end users to use a common public IP address.
In that case, users behind a CGNAT and sharing the same public address might be confused with each other. Therefore, causing problems to calculate view counts and to ban disruptive traffic.
Question
Any alternative to mitigate that?
(Preferably using only Apache)
You could consider unique users are unique combinations of IP+user-agent. It would be a bit better but still wouldn't be able to differentiate users on the same IP and using the same browser, on the same platform.
Other than that, you'd need to use a server side scripting technology and track sessions. That would require cookies tho, which is not too much of a biggie. You can't track static assets using that method tho.
I'm new to LDAP but have a project that requires it*. I'm looking for suggestions on how to organize the database.
There are three components: users, sites and studies. A user belongs to one site and one study; a site can have multiple studies. A site can also have multiple domains (not just DN entries; they might have site1.org, site2.com, and so on.) Finally, some piece of identifying site and study information is being used in another database -- I can't use the name of the site or study but a UID of some sort would work fine.
My initial stab at this has users, sites and study information in three OUs; each entry has a UID guaranteed to be unique for that entity. Each user entry has a site and a study attribute but their distinguished name is "uid=[username],ou=users". Similarly, the site and studies have DNs "uid=[uidvalue],ou=[site|study]"
I have two questions:
1. Does the above schema make sense? I'm only a little ways along now and would like to make sure I'm on the right path before going too far.
2. How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
Thanks for your help!
-j
(*) Because various services on which the system relies use LDAP for authentication -- and, besides, it seems to make architectural sense anyway
I strongly recommend you use existing schemata. For example:
inetOrgPerson for people
organization or organizationalUnit for sites
domain for domains
not sure what is appropriate for study, possibly documentSeries or document.
To answer your questions:
Does the above schema make sense?
Yes. You should beware the tendency to use the hierarchy to represent possibly temporary organization of the objects in the tree. You should use attributes for that, as you are.
How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
I don't see that. Multiple DN entries are OK, or multiple domain sub-objects. If a site has multiple domains it isn't appropriate for domain to be part of the DN.
Is there any way to gracefully remove visitors from a site rather than just putting the site into maintenance and booting everybody out? In particular I am thinking of an eCommerce site where there might be carts open, or even checkouts in progress, but I suppose this would apply to other sites.
Ideally I would envisage a system which would redirect new traffic to a maintenance page; but allow the site to "empty" over a period of time ... and have a monitor of number of visitors and whether they were active.
Does anything like this exist, or what is the industry standard workflow? I usually do maintenance in the middle of the night but that will only work to a certain degree, and not on an international site.
I had to do some maintenance on an eCommerce site yesterday and I used a sitewide notice ( which is available by default with many shopping cart systems; or could be easily achieved using some basic HTML/CSS if not ) .... I made it very prominent and put a clear start time for the maintenance on this notice ... also I started when I said I would.
In the absence of a more foolproof system this lo-fi approach seemed to work well – and maybe that's the best the industry can do at present. I'll leave this here as the answer unless someone comes up with something better.
A friend of mine has opened a local business and not knowing what to do choose a URL with the name of her company (which is a playword). The chosen name is quite bad for google ranking because not meaningful: not indicating the nature of business nor the location (city).
I would like her to buy two new domains:
businessname-business-type-city.com
businessnamebusinesstypecity.com
is that still ok with google? I was doing that some years ago and ranked first on the search.
You can get as many domain names as you want, and set up the DNS to point to the ip of playword. But don't think it would be worth it, and no guarantee it would generate more hits.. Google search take location in consideration, so you're probably best of branding playword, and generate buzz in other ways; social media, flyers, many Google ads, and sponsored posts on Facebook
And be sure to have good semantics on your page
If the domain name is the name of the business then it is meaningful. Value of keywords in domain names has been diminished in recent times. Market the business, not the domain name. (And google local business results will help)
So we have a SharePoint farm that is upon an AD forest, that forest is linked to other forests in a two-way trust.
Then, we have the people picker that is working quite fine and finding every user we try to find, regardless of what domain the user is on.
Now, I need to configure the people picker to find all users from current and future domains in the entirity of the relations BUT one of them. So, it must be a configuration where regardless of what domains, OUs, new or old 2-way trusts are configured, the people picker will find users for all domains BUT one of them.
I've tried to search for an LDAP query that'd do the job to feed to peoplepicker-searchadcustomfilter however could not find it or build it myself. Our AD expert could not get to it too.
I'd rather not use Peoplepicker-searchadforests because later on when they'd add a new domain, someone would have to remember that the people picker needed some configuration. I might be far away when that happens and someone would have to crack his head to find it.
So, from an LDAP Query standpoint, what'd you suggest? Much appreciated.