Suppression of URL details

Discussion in 'HTML' started by coder, Dec 11, 2007.

  1. coder

    coder Guest

    This has probably been answered a 1000 times, but I haven't found it in a
    search.

    I have an application where the user uploads documents and I have logic for
    him to view them. All documents are put into a user specific directory.
    Any give user can only see his documents and documents for which the admin
    level is less than or equal to his admin level (these are stored in a
    database along with file location and other data).

    The problem is that if the user can determine the location of his files,
    then he could construct a URL for other files to which he does not have
    access simply by finding the path , changing a user ID number, and
    guessing/knowing the desired file name to look at. This would be extremely
    difficult if I could make the top level directory dificult to find. So, how
    does one go about hiding the path name to a file in the URL?
     
    coder, Dec 11, 2007
    #1
    1. Advertising

  2. coder wrote:
    > This has probably been answered a 1000 times, but I haven't found it in a
    > search.
    >
    > I have an application where the user uploads documents and I have logic for
    > him to view them. All documents are put into a user specific directory.
    > Any give user can only see his documents and documents for which the admin
    > level is less than or equal to his admin level (these are stored in a
    > database along with file location and other data).
    >
    > The problem is that if the user can determine the location of his files,
    > then he could construct a URL for other files to which he does not have
    > access simply by finding the path , changing a user ID number, and
    > guessing/knowing the desired file name to look at. This would be extremely
    > difficult if I could make the top level directory dificult to find. So, how
    > does one go about hiding the path name to a file in the URL?


    You can't. Anything a user can do from his browser to cause a particular
    document to be downloaded is visible to him because it's visible to the
    browser and is therefore viewable in the source code. If it wasn't
    visible to the browser, the browser wouldn't be able to request it.

    You can either establish the operating system's built-in file security
    mechanism to deny access to materials a user doesn't have the authority
    to see, of you can use an intermediary web application that takes care
    of it:

    http://www.example.com/showdoc?docid=123/456

    where showdoc is a web app (ASP.NET page, PHP page, whatever) that
    checks whether the authenticated user is authorized to see document 456
    belonging to user 123 and, if so, opens it and pipes its contents into
    the response, or else returns an "Access Not Permitted" response.
     
    Harlan Messinger, Dec 11, 2007
    #2
    1. Advertising

  3. coder

    coder Guest

    Harlan Messinger wrote:
    > coder wrote:
    >> This has probably been answered a 1000 times, but I haven't found it
    >> in a search.
    >>
    >> I have an application where the user uploads documents and I have
    >> logic for him to view them. All documents are put into a user
    >> specific directory. Any give user can only see his documents and
    >> documents for which the admin level is less than or equal to his
    >> admin level (these are stored in a database along with file location
    >> and other data). The problem is that if the user can determine the
    >> location of his
    >> files, then he could construct a URL for other files to which he
    >> does not have access simply by finding the path , changing a user ID
    >> number, and guessing/knowing the desired file name to look at. This
    >> would be extremely difficult if I could make the top level directory
    >> dificult to find. So, how does one go about hiding the path name to
    >> a file in the URL?

    >
    > You can't. Anything a user can do from his browser to cause a
    > particular document to be downloaded is visible to him because it's
    > visible to the browser and is therefore viewable in the source code.
    > If it wasn't visible to the browser, the browser wouldn't be able to
    > request it.
    > You can either establish the operating system's built-in file security
    > mechanism to deny access to materials a user doesn't have the
    > authority to see, of you can use an intermediary web application that
    > takes care of it:
    >
    > http://www.example.com/showdoc?docid=123/456
    >
    > where showdoc is a web app (ASP.NET page, PHP page, whatever) that
    > checks whether the authenticated user is authorized to see document
    > 456 belonging to user 123 and, if so, opens it and pipes its contents
    > into the response, or else returns an "Access Not Permitted" response.


    Thanks. While waiting for a response I cam up with a similar solution.
    Upon registration I generate a random eight character code for each new
    user. (The randomness is over 62 possibilies for each character so there
    are 62**8, or about 10**28, possiblities) His upload directory is

    {his userID}_{the random eight character code}

    All uploaded files are given an access level of one by default. All new
    users are given an access level of zero by default. The only files that
    show in a user's list are his own files and those for which he has
    sufficient access level. Upon a click of a file in the list, I do a futher
    check on permissions (a little redundant, but being slightly paranoid) and
    then display that file if it is OK.

    This way, it would be almost impossible for some other user to both know the
    the path to a file that he should not have access to and also know its name.

    Opinions?
     
    coder, Dec 11, 2007
    #3
  4. coder

    Bone Ur Guest

    Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007 17:51:17
    GMT coder scribed:

    >> You can either establish the operating system's built-in file
    >> security mechanism to deny access to materials a user doesn't have
    >> the authority to see, of you can use an intermediary web application
    >> that takes care of it:
    >>
    >> http://www.example.com/showdoc?docid=123/456
    >>
    >> where showdoc is a web app (ASP.NET page, PHP page, whatever) that
    >> checks whether the authenticated user is authorized to see document
    >> 456 belonging to user 123 and, if so, opens it and pipes its contents
    >> into the response, or else returns an "Access Not Permitted"
    >> response.

    >
    > Thanks. While waiting for a response I cam up with a similar
    > solution. Upon registration I generate a random eight character code
    > for each new user. (The randomness is over 62 possibilies for each
    > character so there are 62**8, or about 10**28, possiblities) His
    > upload directory is
    >
    > {his userID}_{the random eight character code}
    >
    > All uploaded files are given an access level of one by default. All
    > new users are given an access level of zero by default. The only
    > files that show in a user's list are his own files and those for which
    > he has sufficient access level. Upon a click of a file in the list, I
    > do a futher check on permissions (a little redundant, but being
    > slightly paranoid) and then display that file if it is OK.
    >
    > This way, it would be almost impossible for some other user to both
    > know the the path to a file that he should not have access to and also
    > know its name.
    >
    > Opinions?


    Why don't you just impliment a password scheme? P/ws could be db-linked
    to usernames and access levels, etc.

    --
    Bone Ur
    Cavemen have formidable pheromones.
     
    Bone Ur, Dec 11, 2007
    #4
  5. On Dec 11, 11:19 am, "coder" <> wrote:
    > This has probably been answered a 1000 times, but I haven't found it in a
    > search.
    >
    > I have an application where the user uploads documents and I have logic for
    > him to view them. All documents are put into a user specific directory.
    > Any give user can only see his documents and documents for which the admin
    > level is less than or equal to his admin level (these are stored in a
    > database along with file location and other data).
    >
    > The problem is that if the user can determine the location of his files,
    > then he could construct a URL for other files to which he does not have
    > access simply by finding the path , changing a user ID number, and
    > guessing/knowing the desired file name to look at. This would be extremely
    > difficult if I could make the top level directory dificult to find. So, how
    > does one go about hiding the path name to a file in the URL?


    Google for mod_rewrite tutorial (assuming your running Apache, I don't
    know what the equivalent on a Windows server is).

    Nick

    --
    Nick Theodorakis

    contact form:
    http://theodorakis.net/contact.html
     
    Nick Theodorakis, Dec 11, 2007
    #5
  6. coder

    coder Guest

    Bone Ur wrote:
    > Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007
    > 17:51:17 GMT coder scribed:
    >
    >>> You can either establish the operating system's built-in file
    >>> security mechanism to deny access to materials a user doesn't have
    >>> the authority to see, of you can use an intermediary web application
    >>> that takes care of it:
    >>>
    >>> http://www.example.com/showdoc?docid=123/456
    >>>
    >>> where showdoc is a web app (ASP.NET page, PHP page, whatever) that
    >>> checks whether the authenticated user is authorized to see document
    >>> 456 belonging to user 123 and, if so, opens it and pipes its
    >>> contents into the response, or else returns an "Access Not
    >>> Permitted" response.

    >>
    >> Thanks. While waiting for a response I cam up with a similar
    >> solution. Upon registration I generate a random eight character code
    >> for each new user. (The randomness is over 62 possibilies for each
    >> character so there are 62**8, or about 10**28, possiblities) His
    >> upload directory is
    >>
    >> {his userID}_{the random eight character code}
    >>
    >> All uploaded files are given an access level of one by default. All
    >> new users are given an access level of zero by default. The only
    >> files that show in a user's list are his own files and those for
    >> which he has sufficient access level. Upon a click of a file in the
    >> list, I do a futher check on permissions (a little redundant, but
    >> being slightly paranoid) and then display that file if it is OK.
    >>
    >> This way, it would be almost impossible for some other user to both
    >> know the the path to a file that he should not have access to and
    >> also know its name.
    >>
    >> Opinions?

    >
    > Why don't you just impliment a password scheme? P/ws could be
    > db-linked to usernames and access levels, etc.


    I already have one in place. The problem I was solving was that for someone
    who logged into his own account could see the path for the files he
    uploaded. Then, by modifying the path a little he might be able to see
    someone else files just by putting in that URL without even logging in. My
    scheme that I cam up with makes that extremely difficult, if not next to
    impossible.
     
    coder, Dec 11, 2007
    #6
  7. coder

    coder Guest

    One more thing. A user can always do "Save As" for a web page and pull it
    down to his computer. That's fine. However, what is the software behind
    when a user clicks "Download" and the actual file comes down.
     
    coder, Dec 11, 2007
    #7
  8. coder

    Bone Ur Guest

    Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007 23:38:02
    GMT coder scribed:

    >> Why don't you just impliment a password scheme? P/ws could be
    >> db-linked to usernames and access levels, etc.

    >
    > I already have one in place. The problem I was solving was that for
    > someone who logged into his own account could see the path for the
    > files he uploaded. Then, by modifying the path a little he might be
    > able to see someone else files just by putting in that URL without
    > even logging in. My scheme that I cam up with makes that extremely
    > difficult, if not next to impossible.


    What url, -the directory? You can block general access to a folder with an
    ..htaccess file or even just putting an index.html in that folder. It's
    even possible to p/w-protect a folder, though I've never done it.
    Furthermore, as a hypothetical example and assuming that the passwords are
    unique and unknown to other users, you could name the folders the passwords
    (or something similarly secure). Heck, if you're really paranoid and use
    php, you can create folders on the fly for each logon, transfer files, then
    delete the lot after a certain time.

    --
    Bone Ur
    Cavemen have formidable pheromones.
     
    Bone Ur, Dec 12, 2007
    #8
  9. coder wrote:

    > The problem is that if the user can determine the location of his files,
    > then he could construct a URL for other files to which he does not have
    > access simply by finding the path , changing a user ID number, and
    > guessing/knowing the desired file name to look at.


    Send a 403 error if he doesn't have the required authorization.

    Use HTTP authentication and authorization.
    For Apache, the HOWTO tutorial is at:
    http://httpd.apache.org/docs/2.2/howto/auth.html

    > This would be extremely
    > difficult if I could make the top level directory dificult to find.


    This would also be extremely unsecure.
    Security by obfuscation is obsolete since the twentieth century.

    --
    If you've a question that doesn't belong to Usenet, contact me at
    <tabkanDELETETHISnaz at yahoDELETETHATo.fr>
     
    André Gillibert, Dec 13, 2007
    #9
  10. André Gillibert wrote:
    > coder wrote:
    >
    >> The problem is that if the user can determine the location of his files,
    >> then he could construct a URL for other files to which he does not have
    >> access simply by finding the path , changing a user ID number, and
    >> guessing/knowing the desired file name to look at.

    >
    > Send a 403 error if he doesn't have the required authorization.
    >
    > Use HTTP authentication and authorization.
    > For Apache, the HOWTO tutorial is at:
    > http://httpd.apache.org/docs/2.2/howto/auth.html
    >
    >> This would be extremely
    >> difficult if I could make the top level directory dificult to find.

    >
    > This would also be extremely unsecure.
    > Security by obfuscation is obsolete since the twentieth century.


    Public key encryption is nothing more than security by extreme
    obfuscation. In that case, you're relying on a third party not to
    stumble on the value of a private key, which is selected using a method
    that causes that to be highly unlikely. Using a path generation method
    where genuine paths are only a minuscule fraction of all possible paths
    can be plenty secure.
     
    Harlan Messinger, Dec 13, 2007
    #10
  11. coder

    Andy Dingley Guest

    On 13 Dec, 17:21, Harlan Messinger <>
    wrote:

    > Public key encryption is nothing more than security by extreme
    > obfuscation.


    Only if you stretch the terms beyond the breaking point of their usual
    meanings.

    "extreme" here means a level of difficulty (for competent
    implementations) that makes it technically impossible for the socially
    significant lifetime of the data protected. Comptent work involves
    assessing both of these: necessary lifetime and predicted point at
    which brute-force cracking becomes practical.

    Enigma didn't fail because modern PCs can break it today, it failed
    because Bletchley Park pushed the cryptanalysis technology further
    forward more quickly than was expected, and (mainly) because of errors
    in its operation. It doesn't matter to Hitler that we can read them
    today with our incredible computing powers, it did matter that they
    were unexpectedly readable within a useful time.
     
    Andy Dingley, Dec 13, 2007
    #11
  12. Andy Dingley wrote:
    > On 13 Dec, 17:21, Harlan Messinger <>
    > wrote:
    >
    >> Public key encryption is nothing more than security by extreme
    >> obfuscation.

    >
    > Only if you stretch the terms beyond the breaking point of their usual
    > meanings.
    >
    > "extreme" here means a level of difficulty (for competent
    > implementations) that makes it technically impossible for the socially
    > significant lifetime of the data protected. Comptent work involves
    > assessing both of these: necessary lifetime and predicted point at
    > which brute-force cracking becomes practical.
    >
    > Enigma didn't fail because modern PCs can break it today, it failed
    > because Bletchley Park pushed the cryptanalysis technology further
    > forward more quickly than was expected, and (mainly) because of errors
    > in its operation. It doesn't matter to Hitler that we can read them
    > today with our incredible computing powers, it did matter that they
    > were unexpectedly readable within a useful time.
     
    Harlan Messinger, Dec 13, 2007
    #12
  13. Andy Dingley wrote:
    > On 13 Dec, 17:21, Harlan Messinger <>
    > wrote:
    >
    >> Public key encryption is nothing more than security by extreme
    >> obfuscation.

    >
    > Only if you stretch the terms beyond the breaking point of their usual
    > meanings.


    The word "extreme" already means "at or beyond the limits". How can
    "extreme" be stretched beyond that meaning? Your objection makes no
    sense as stated.

    > "extreme" here means a level of difficulty (for competent
    > implementations) that makes it technically impossible for the socially
    > significant lifetime of the data protected. Comptent work involves
    > assessing both of these: necessary lifetime and predicted point at
    > which brute-force cracking becomes practical.
    >
    > Enigma didn't fail because modern PCs can break it today, it failed
    > because Bletchley Park pushed the cryptanalysis technology further
    > forward more quickly than was expected, and (mainly) because of errors
    > in its operation. It doesn't matter to Hitler that we can read them
    > today with our incredible computing powers, it did matter that they
    > were unexpectedly readable within a useful time.


    How does all this alter the validity of my remark?
     
    Harlan Messinger, Dec 13, 2007
    #13
  14. coder

    Andy Dingley Guest

    On 13 Dec, 18:54, Harlan Messinger <>
    wrote:
    > Andy Dingley wrote:
    > > On 13 Dec, 17:21, Harlan Messinger <>
    > > wrote:

    >
    > >> Public key encryption is nothing more than security by extreme
    > >> obfuscation.

    >
    > > Only if you stretch the terms beyond the breaking point of their usual
    > > meanings.

    >
    > The word "extreme" already means "at or beyond the limits". How can
    > "extreme" be stretched beyond that meaning?


    I don't object to "extreme", so much as it's use to qualify
    "obfuscation".

    You appear to be using obfuscation to imply "camouflage" (potentially
    discoverable, with effort) and qualifying it with "extreme" makes it
    hard to find fault with the statement. PK (for practical algorithms,
    such as factorising the products of long primes) is of course merely
    obfuscation because we know exactly _how_ to break it, it's just that
    we cannot do this (for any practical or anticipated approach).

    Yet the phrase "extreme obfuscation" still embodies the term
    "obfuscation", and the impression that will inevitably generate in the
    mind of the reader is as something that's basically insecure. Weasel
    words, used to create an impression that PK is somehow insecure,
    without going so far as to make a statement that's provably false.
    "When did you stop beating your wife?"

    There's also the issue that "obfuscation" in the crypto world is
    generally used to mean a process that's deliberately lossy and thus
    absolutely irreversible (albeit thus no use for encryption), eg.
    displaying only the last 4 or 5 digits of a card number.
     
    Andy Dingley, Dec 18, 2007
    #14
  15. Andy Dingley wrote:
    > On 13 Dec, 18:54, Harlan Messinger <>
    > wrote:
    >> Andy Dingley wrote:
    >>> On 13 Dec, 17:21, Harlan Messinger <>
    >>> wrote:
    >>>> Public key encryption is nothing more than security by extreme
    >>>> obfuscation.
    >>> Only if you stretch the terms beyond the breaking point of their usual
    >>> meanings.

    >> The word "extreme" already means "at or beyond the limits". How can
    >> "extreme" be stretched beyond that meaning?

    >
    > I don't object to "extreme", so much as it's use to qualify
    > "obfuscation".
    >
    > You appear to be using obfuscation to imply "camouflage" (potentially
    > discoverable, with effort) and qualifying it with "extreme" makes it
    > hard to find fault with the statement.


    So your objection is that you wanted to pick apart my statement but I
    didn't leave room for you to do so, so you tried to recast my remark in
    a manner that would let you pick it apart, and I caught your bluff.
    Sorry for the inconvenience.

    > PK (for practical algorithms,
    > such as factorising the products of long primes) is of course merely
    > obfuscation because we know exactly _how_ to break it, it's just that
    > we cannot do this (for any practical or anticipated approach).
    >
    > Yet the phrase "extreme obfuscation" still embodies the term
    > "obfuscation", and the impression that will inevitably generate in the
    > mind of the reader is as something that's basically insecure. Weasel
    > words, used to create an impression that PK is somehow insecure,
    > without going so far as to make a statement that's provably false.


    It isn't false, so how could I make it provably false? Don't explain
    "falsifiability" to me--I already understand it just fine. There isn't
    anything unfalsifiable about what I said. You just want to believe that
    PK is inherently secure, and my point was that its security lies
    *solely* in the impracticality of testing quadrillions or quintillions
    or however many -illions of possible keys would be necessary to hit upon
    the one that was used in the encryption. This differs from the case we
    were discussing with respect to the OP's situation only in orders of
    magnitude, and if ten years from now processors become octillions of
    times faster than they are now, PK keys would be broken like *that*.
    This isn't news. It's obvious and well-known to everyone in the field.
    So as I said, the only difference is the order of magnitude, and, as I
    said, PK is an extreme case.

    > "When did you stop beating your wife?"
    >
    > There's also the issue that "obfuscation" in the crypto world is
    > generally used to mean a process that's deliberately lossy and thus
    > absolutely irreversible (albeit thus no use for encryption), eg.
    > displaying only the last 4 or 5 digits of a card number.
     
    Harlan Messinger, Dec 18, 2007
    #15
  16. coder

    Andy Dingley Guest

    On 18 Dec, 16:12, Harlan Messinger <>
    wrote:

    > So your objection is that you wanted to pick apart my statement but I
    > didn't leave room for you to do so, so you tried to recast my remark in
    > a manner that would let you pick it apart, and I caught your bluff.
    > Sorry for the inconvenience.


    OK, I'll make it simple for you: Disparaging PK as "no more than
    obfuscation" (either "obfuscation" or "extreme obfuscation") is
    disingenuous bollocks.
    Happy now?
     
    Andy Dingley, Dec 18, 2007
    #16
  17. Andy Dingley wrote:
    > On 18 Dec, 16:12, Harlan Messinger <>
    > wrote:
    >
    >> So your objection is that you wanted to pick apart my statement but I
    >> didn't leave room for you to do so, so you tried to recast my remark in
    >> a manner that would let you pick it apart, and I caught your bluff.
    >> Sorry for the inconvenience.

    >
    > OK, I'll make it simple for you: Disparaging PK as "no more than
    > obfuscation" (either "obfuscation" or "extreme obfuscation") is
    > disingenuous bollocks.
    > Happy now?


    Fine. And I'm still right, and you're still wrong.
     
    Harlan Messinger, Dec 18, 2007
    #17
  18. Harlan Messinger wrote:
    > Andy Dingley wrote:
    >> On 18 Dec, 16:12, Harlan Messinger <>
    >> wrote:
    >>
    >>> So your objection is that you wanted to pick apart my statement but I
    >>> didn't leave room for you to do so, so you tried to recast my remark in
    >>> a manner that would let you pick it apart, and I caught your bluff.
    >>> Sorry for the inconvenience.

    >>
    >> OK, I'll make it simple for you: Disparaging PK as "no more than
    >> obfuscation" (either "obfuscation" or "extreme obfuscation") is
    >> disingenuous bollocks.
    >> Happy now?

    >
    > Fine. And I'm still right, and you're still wrong.


    To make it more specific, I've explained why I'm right, and nothing
    you've said contradicts me, and almost as if to prove that point you
    resorted to attack mode. If I'm really incorrect, would you please
    provide something informative that demonstrates that fact instead of
    waving your hands and calling it bollocks?

    I don't understand what your problem is with it: there isn't anything
    controversial or surprising about it to anyone who understands it. It
    may be *disturbing* to anyone who thought that there was anything more
    to it than there actually is and who, given genuine information on the
    subject, is seized with visions of all our current modes of security
    disappearing twenty years from now if someone designs a processor that's
    orders of magnitudes more powerful than the ones we have now.

    In one sense, that fear is well grounded: eventually, if processor
    speeds keep improving, then, for example, our current 128-bit or 256-bit
    key SSL encryption will break like a stick! (This is OBVIOUS. It's the
    same reason why we don't use, say, only *16-bit* encryption now!) But on
    the other hand the day is saved, because it will likewise be no more
    time-consuming to use, say, 2048-bit encryption once that time has come
    than it is now to use 128-bit encryption.
     
    Harlan Messinger, Dec 18, 2007
    #18
  19. coder

    dorayme Guest

    In article
    <
    m>,
    Andy Dingley <> wrote:

    > OK, I'll make it simple for you: ... is
    > disingenuous bollocks.
    > Happy now?


    Psychiatrist: You're mad.

    Patient: I want a second opinion.

    Psychiatrist: OK, You're also fat and ugly.

    --
    dorayme
     
    dorayme, Dec 19, 2007
    #19
  20. coder

    dorayme Guest

    In article
    <
    m>,
    Andy Dingley <> wrote:

    > I don't object to "extreme", so much as it's use to qualify
    > "obfuscation".
    >
    > You appear to be using obfuscation to imply "camouflage" (potentially
    > discoverable, with effort)


    Anyway... without wanting to get involved between this business
    with Harlan and you, it did make me wonder how to categorize a
    kill-switch I am fond of wiring up for friend's cars.

    I like the idea of not hiding a switch because the damn thing can
    be found if the thief suspects it is somewhere. I prefer to put
    it right under his nose where there is nothing like a simple
    verification procedure for finding it:

    Ah! A toggling thingmajig, click, click!

    No. Best for it not to physically be this at all.

    Next there is another layer of ? obfus... what was the word?
    Anyway, I have a scheme to discourage the thief even suspecting a
    kill switch. Or at least to encourage a different theory in his
    evil head, namely that the car is just hard to start or flooded
    or out of petrol. I can reveal that I do this by ensuring the
    starter motor is *not* disabled.

    Naturally I can say no more. But I need a name for the general
    scheme. Perhaps I might patent it. (btw. anyone interested in
    investing, please send $US10 without asking anything in return -
    to show good faith.)

    --
    dorayme
     
    dorayme, Dec 19, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven Buroff
    Replies:
    5
    Views:
    5,540
    Alan Moore
    Sep 28, 2004
  2. Replies:
    0
    Views:
    989
  3. , India

    question on assignment suppression in scanf

    , India, Oct 18, 2008, in forum: C Programming
    Replies:
    2
    Views:
    380
    Ben Bacarisse
    Oct 18, 2008
  4. Bart Vandewoestyne

    assignment suppression in sscanf

    Bart Vandewoestyne, Apr 27, 2010, in forum: C Programming
    Replies:
    3
    Views:
    5,083
    Ben Bacarisse
    Apr 27, 2010
  5. Alf P. Steinbach

    Ann: MSVC sillywarning suppression

    Alf P. Steinbach, Jun 15, 2010, in forum: C++
    Replies:
    2
    Views:
    476
    Alf P. Steinbach
    Jun 15, 2010
Loading...

Share This Page