From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news4.google.com!feeder.news-service.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Followup-To: comp.lang.ada Date: Mon, 01 Aug 2011 11:30:33 +0200 Organization: A noiseless patient Spider Message-ID: References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Injection-Date: Mon, 1 Aug 2011 09:30:34 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="M7rP6jhm1IVgvmYaXQFuIA"; logging-data="32458"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ro21EDGLjDkjN5oXZMKZI" User-Agent: KNode/4.4.10 Cancel-Lock: sha1:0baEnT/6viFQmtV53eKpLCfspsU= Xref: g2news1.google.com comp.lang.ada:20437 Date: 2011-08-01T11:30:33+02:00 List-Id: Simon Wright wrote: > "Randy Brukardt" writes: > >> "Simon Wright" wrote in message >> news:m2sjpp4mar.fsf@pushface.org... >>> "Randy Brukardt" writes: >>> >>>> The design was driven by an extra-paranoid approach to security: if >>>> the server had any way for a URL to execute foreign code (a >>>> plug-in), then it is highly likely that an attacker would find a way >>>> to use buggy URL to execute some foreign code of their choice. Thus >>>> the ability to execute foreign code is not provided at all -- all >>>> handlers have to compiled into the web server. (Combined with Ada's >>>> near prevention of buffer overflows and stack attacks, the two most >>>> common vectors of the time were firmly plugged. Of course, traversal >>>> prevention and sanitization of parameters still have to be >>>> accomplished -- there is no silver bullet to security.) Once you've >>>> done that, there isn't much benefit to an OOP approach, since you >>>> have to enumerate all of the handlers somewhere in any case. >>> >>> Interesting. I'd have thought that "implementing the server using >>> OOP" and "not providing plugin facilities" were quite separate >>> things. The OOP approach could, I suppose, be thought of as a way to >>> provide you (Randy) with plugin facilities, but not attackers! >> >> The root of the problem is that Ada 95 had no way to create a factory >> short of writing a giant case statement. That's annoying but OK if you >> have a complex interface with many operations to implement. However, >> the web server only has a single interface ("here's a URL and a >> socket, write the result to the socket"). So there is no advantage to >> having a separate case statement in the factory - that would just add >> complexity. (The output to the socket has many helper routines in >> order to make it easier to write the correct formats, but in any case >> the output is nearly free-form text and there is no obvious advantage >> to any extensions there.) >> >> Even in Ada 2005 (which has somewhat better support for factories), >> you still have to "with" all of the units involved. It isn't much >> harder to write calls into a case statement (especially given the >> simplity of the interface). > > In my EWS (https://sourceforge.net/projects/embed-web-srvr/) there are > two 'classes' of response, Static and Dynamic. For static responses, the > page to be returned is fixed, and is baked in at build time. For dynamic > responses, I have a function > > type Creator > is access function (From_Request : HTTP.Request_P) > return Dynamic_Response'Class; > > and a means of registering Creators > > procedure Register (The_Creator : Creator; For_The_URL : HTTP.URL); > > ('URL' isn't quite right, it's the 'abs_path [ "?" query ]' part of an > HTTP URL, eg /embed-web-srvr/ in the URL above). > > For_The_URL is really a String, and the result of registration is > effectively a run-time factory. But no case statements! I have done basically the same for my component-based robotic library, but still you have to /with/ all the units you want and call the register procedure... Still, I find this sufficiently neat (you don't have to edit any central piece of code (besides the main procedure, but that's OK to me --you're expressing your necessities there).