I have a service based business with no physical customer facing address. I can't seem to wrap my head around implementing a schema markup for a business like this but I'm sure I'm not the only one in such a position.
I've read that localbusiness is a local business (which we are) but it requires an address, I'd prefer not to display my address publicly, but that ship has already sailed for the most part. I know service falls under a localbusiness so I don't think that helps either.
Did I miss something?
The address property does not imply that it’s a customer-facing address.
The publicAccess property allows to specify whether or not the LocalBusiness allows visitors:
{
"#context": "http://schema.org",
"#type": "LocalBusiness",
"address": {
"#type": "PostalAddress"
},
"publicAccess": false
}
That said, Schema.org doesn’t require any property. It’s perfectly fine to have a LocalBusiness without address. Certain data consumers might require certain properties for certain features; their documentation hopefully makes clear how they interpret the properties (e.g., if they require address and understand it to be a customer-facing address, the feature they offer is probably not intended for your case anyway; and they should ideally change their understanding of it, because there will be many addresses that aren’t intended to be visited by customers).
Related
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
I am trying to make a REST application where I try to hide to hide Business Logic from request and responses.
I have to examples which I don't know how to handle.
First example: I have a shopping cart and product x can't be ordered with product y. The client however decided to order them both. How can I give a proper error message or guide the client that this isn't allowed. Because giving an error saying "x and y are not allowed together" seems like exposing Business Logic to me.
The structure is in place because of different services that we have. The products can be re-used, but the order intake is different. For example we can offer an order intake for vehicles which need different configuration when ordering cloths. In both cases you will have product, which have name and price and therefore can be re-used. That's is why vehicles and cloths can't be ordered together and shouldn't. To make this more user friendly there will be a service which presents available options for the specific order intake. But there should be a part which validates it and gives proper error on this.
Second example: A client has one pending order and can't create a new order when the pending order is completed. This seems/feels stateful to me and should probably avoided. How should this be handled?
UPDATE So resolving the issue for my first example could be to create an endpoint something like /products?type=vehicle or /products/combinations?type=vehicle. This is for displaying the allowed products/combinations and have an endpoint /order to put the products in where the validation happens. These endpoints can stand on their own, but the context may come from somewhere else. Do I understand correctly?
As the other answer already pointed out, this is only marginally related to REST, it has I think more to do with the meaning of "exposing business logic" and "statelessness".
The first point of not wanting to expose business logic: It is only exposing business logic if some system really needs to interpret the specific error. If it is "only" supplying a localized message to the user, it is not exposing any logic to the systems in between. The frontend system does not need to know what is going on, it only needs to display the message from the backend system.
There are cases when the frontend system needs to know, to be able to guide the user. It is not fundamentally wrong to expose business logic, as long as it is not implicitly exposed, but explicitly part of the interface description.
On the second point about statelessness: REST defines that the communication needs to be stateless. That means any arbitrary request from client should be meaningful without the context of any previous messages (this includes previous logins, sessions, whatever). Each request stands on its own. This does not mean that specific resources can not keep a state of their own. A shopping cart on the backend does in fact has a state, this is OK.
Or said differently: Can the next request hit a different server and still be successful? And I mean without session replication, distributed cache or other magic. If yes, the communication is stateless. If you need "sticky" sessions or such things, then no, you are not stateless.
I think your questions are not entirely related to REST itself but I will try to answer them anyways. Maybe, you can give more details about what bothers you reading my answers.
I am not completely sure how the first question is related to REST because I feel it is about wording. The question to me would be: Why is it not allowed to order both of these products together? So, you cannot but them into the same shopping basket? This would not be really user-friendly, so the best idea would be to allow it. If you cannot change that both are not allowed at the same time, I would just "grey out" all the items that are not allowed together with product X if it is already in the shopping basket.
However, this is more of a user experience question. Maybe, you could go into detail here in what exact case a user could be insert both of the products at the same time, while it is not allowed.
Towards your second question: In most online shops you usually have a state that is either mapped to the account, a session or via cookies. If you truly want to have a stateless API here with REST, you could work with order IDs. These could be passed to each request. Of course, the order itself has a state. But the requests do not have one.
Notice: REST does not mean much. You basically have no state for each request and have all information in the URL that are necessary.
Maybe, this helps a bit already.
I'm writing a piece of software that will run on computers as well as phones.
The service uses an HTTP API for communication and will be published over the local network using Zeroconf.
Initially I published my service using _http._tcp. as the service type but I quickly discovered that both my NAS and my music receiver(!) also broadcasts themselves with that exact service type.
So the question now arises how to differentiate between my service and other services that are using HTTP.
Alternatives
Using a different service type
The is certainly the most certainly the easiest way and (almost) guarantees no other services will be picked up.
However, according to Apple1 new services should be registered with IANA. This is obviously not required but seeing as they recommend it it feels like it would be the wrong way to do it
Using the TXT record
Apple2 describes the TXT record like this:
When a service is registered, three related DNS records are created: a service (SRV) record, a pointer (PTR) record, and a text (TXT) record. The TXT record contains additional data needed to resolve or use the service, although it is also often empty.
The certainly feels like it could be the right way to do it, but I'm still not sure and it's hard to find a description of what the field should contain.
My first though would be to put something like <service_name>-<version> which will then be parsed to see which service it actually is.
My NAS seems to use this for identifying model and version numbers.
Try talking to the service
After finding a service one could always perform a HEAD request on a known endpoint and look for a known header set by the service.
This feels like a fairly slow approach and who knows what making a HEAD request to my receiver will do.
And just to be clear, this question has nothing to do with a specific language or framework, it's about the concepts of zeroconf.
I could show some code but I don't see how that would help.
First, does the service you're advertising actually meet the qualifications for _http as defined by RFC 2782. Specifically- is it not just using HTTP for a transport but is also:
can be displayed by "typical" web browser client software, and
is intended primarily to be viewed by a human user.
If no, register your own service type (there are a couple other services that use HTTP as a transport but don't meet those qualifications so they have -http as a suffix to the service name, see pgpkey-http, senteo-http, xul-http).
If yes, there are a couple ways to go depending on how strict one's interpretation of the RFC is. The least strict being just adding a TXT record as you've already noted in your question. iTunes registers itself with a TXT record in the format iTSh Version=196618.
If you're feeling a little more strict, the RFC only explicitly states that the u=, p= and path= TXT records exist for HTTP. Perhaps someone can chime in on this, but I haven't seen much discussion on whether adding TXT records to already existing entries is frowned upon or not. So with that, the other way is to just an algorithmic instance name. For example, adding the suffix "-NicklasAService" to the device name. Hopefully giving it a unique name to the local network but still making it so that the service can be easily picked out by the PTR record by just looking for the suffix.
I've been reading up on 'real' RESTful APIs for a few days now, and I think I'm near to groking what it's about.
But one of the things that I stumble on is that I can't even begin to imagine how one would write a client for a 'real' hypermedia API:
Most of the examples I've read talk about browsers and spiders, but that's not especially helpful: one is human-directed and 'intelligent', the other is dumb and 'random'. As it stands, I kind of get the impression that you'd need to learn AI to get a client working.
One thing that isn't clear to me is how the client knows which verb to use on any given link? Is that implicit in the 'rel' type of the uri? The alternative (reading here) seems to be using xhtml and having a client which can parse and post forms.
How likely is it that a link will change, but not the route to the link?
In most examples you see around, the route and the link are the same:
eg. if I want to set up a client which will bring me back the list of cakes from Toni's Cake Shop:
http://tonis.com
{ link: { type : "cakes" ; uri : "http://tonis.com/cakes" } }
What happens when Toni's becomes Toni's Food Shop, and the link becomes http://tonis.com/desserts/cakes?
Do we keep the initial cakes link at the root, for reverse-compatibility? And if not, how do we do a 'redirect' for the poor little agent who has been told "go to root, look for cakes"?
What am I missing?
Ok, I'm not a REST expert either, I've been reading much related stuff lately, so what I'm going to write is not my experience or opinion but rather a summary of what I read, especially, the REST In Practice book.
First of all, you can't escape from having some initial agreement between client and server, the goal of REST is to make them agree on the very minimum of things which are relevant to both of them and let each party care about their own stuff themselves. E.g., client should not care about links layout or how the data is stored on server, and server should not care about a client's state. What they agree on in advance (i.e. before the interaction begins) is what aforementioned book's authors call "Domain Application Protocol" (DAP).
The important thing about DAP is that it's stateful, even though HTTP itself is not (since any client-service interaction has state, at least, begin and end). This state can be described in terms of "What a client can/may/is expected to do next": "I've started using the service, what now? Ok, I can search items. Search this item, what's next? Ok, I can order this and that... etc"
The definition of Hypermedia content-type is being able to handle both data exchange and interaction state. As I already mentioned, state is described in terms of possible actions, and as comes from "Resource" in REST, all actions are described in terms of accessible resources. I guess, you have seen the acronym "HATEOAS (Hypermedia as the engine of application state), so that's what it apparently means.
So, to interact with the service, a client uses a hypermedia format they both understand, which can be standard, homegrown or a mixture of those (e.g. XML/XHTML-based). In addition to that, they must also share the protocol, which is most likely HTTP, but since some details are omitted from the standard, there must be some idioms of its usage, like "Use POST to create a resource and PUT to update". Also, such protocol would include the entry points of the service (again, in terms of accessible resources).
Those three aspects fully define the domain protocol. In particular, a client is not supposed to know any internal links before it starts using the service or remember them after the interaction completes. As a result, any changes in the internal navigation, like renaming /cakes to /f5d96b5c will not affect the client as soon as it adhere the initial agreement and enters the shop through the front door.
#Benjol
You must avoid to program clients against particular URI's. When you describe a link main importance has it's meaning and not URI itself. You can change the URI any time, though this shouldn't break your client.
I'd change your example this way:
{"link": {
"rel": "collection http://relations.your-service.com/cakes",
"href": "http://tonis.com/cakes",
"title": "List of cakes",
"type": "application/vnd.yourformat+json"
}}
if there is a client which consumes your service, it needs to understand:
link structure itself
link relationships(in this case "collection" which is RFC and
"http://relations.your-service.com/cakes" which is your domain
specific link relation)
In this case client can just dereference address specified by "href" attribute and display list of cakes. Later, if you change the cake list provider URI client will continue to work, this implies that client still understands semantics of your media type.
P.S.
See registered link relation attributes:
http://www.iana.org/assignments/link-relations/link-relations.xml
Web Linking RFC: https://www.rfc-editor.org/rfc/rfc5988
UPDATED
overview of the problem
I am developing a public idea sharing
website, where any user(after creating
an account) can submit ideas; they
will then be reviewed & rated by our
internal reviewers. And only the best
submitted ideas will be published.
These ideas can now be voted by anyone
anonymously. And for each 1000 idea
votes, we will reward idea authors
with say $0.5.
I'm using an anonymous voting system where each vote is identified by a combination of IP address and User-agent.
But since we are rewarding users with cash , I fear this voting system could be manipulated!
Measures I've thought of taking:
Voting only with javascript enabled( using ajax) - to make sure votes come from browsers alone.
Also considering to receive votes, only from the most commonly used browsers.
Can this kind of voting work effectively without much loopholes?
Any good solutions for anonymous voting systems?
Wow! this link is helpful: What is a reliable method to record votes from anonymous users, without allowing duplicates
authentication based on the users account (credit card, checking account ..) Or how is the money payed out?
This won't work. People can easily masquerade under a different user agent, regardless of whether or not it's a "commonly used browser" or if Javascript is enabled. It doesn't make any sense why you think limiting voting to users with common browsers will do anything at all. Client-side scripts could also be written to cast votes, even if you require Javascript to be enabled. Not even IP addresses are immune from spoofing; for example, the user could work from behind a proxy server. Also consider that there could be more than one user who shares the same IP: dynamic IP addresses are quite common, and large ISPs frequently re-use IP addresses by allocating them to different users at different times.
I already voted to close this as off-topic, but it looks like it's also a duplicate: Limit 1 vote per IP Address?