Home/ Questions/Q 518763
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T07:58:14+00:00

I’m building an XML-based webservice in Rails to serve as the backend for an

  • 0

I’m building an XML-based webservice in Rails to serve as the backend for an iPhone app, and I’m wondering how I can best achieve an auth scheme that will let me use both GET and POST requests — i.e. one that doesn’t require auth sent in the body of an XML payload.

The wrinkle here is that I’m not using regular HTTP auth. Instead, I’m creating a SHA1 digest of the iPhone’s hardware ID (concatenated w/ a “secret” string pre-digest) along with the unhashed ID. I validate it on the server by attempting to re-create the digest w/ the hardware ID from the request and matching it against the hashed hardware ID from the request.

My question is this: should I create my service so that every action on every resource expects a payload of POSTed XML containing the security context in a common XML structure, or is there a better way to do it?

In other words, I’d like to use GET for things like /show, /index, etc. But as my app currently stands, I can’t do that, since I need to send an XML payload containing the security context.

Perhaps there’s a good way to achieve effectively the same thing with headers a la Google’s web API’s?

Every security context looks like this:

<request-wrapper>
    <security-context>
        <username>joefoo</username>
        <hardware-id>AE7D128BCA9206E59901</hardware-id>
        <hashed-hardware-id>cfd7983850301f97f6fdc26b553d1b6170f18bde</hashed-hardware-id>
    </security-context>
    ...
    (remainder of request payload)
    ...
</request-wrapper>

This is my first XML service in Rails, so I’d appreciate any general practice advice in this vein as well.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your authentication scheme is subject to replay attacks if the “secret string” stays the same over the lifetime of the device.

    Additionally, the “secret key” (if it is embedded in your application) can be dumped via strings (or other tool) breaking your scheme entirely.

    I would instead use an asymmetric key to setup a one-time secret key, and then use it to hash a counter or something. If you need the hardware id for some reason, hash it plus the counter. This is basically a dumbed down SSL implementation, so you might as well just do that frankly (generating your own certificate, and doing the rare mutual authentication; but still…).

    Remember, inventing your own security scheme is almost always a bad idea.

    • 0