Re: Suppressing Primary Keys in Direct Action URLs
Re: Suppressing Primary Keys in Direct Action URLs
- Subject: Re: Suppressing Primary Keys in Direct Action URLs
- From: Colin Clark <email@hidden>
- Date: Tue, 5 Oct 2004 14:02:28 -0400
Hi Janice,
It does sound like you're using DirectActions here in a situation where
they're not altogether advantageous.
If you use a component action, the URL will be transient and scoped to
a particular session. In other words, it won't be "guessable." If you
do switch to using component actions, however, it does mean that users
can't bookmark their own certificate page.
Some alternatives if you need to continue using direct actions for
bookmark-ability:
1. Make the direction action session-based. Require that your PDF
generator checks who is logged in and ensures that they are authorized
to access the particular certificate document they're trying to
generate.
2. Create some kind of randomized or encrypted scheme for invoking your
PDF generator action to ensure that an unauthorized user can't access
other users' certificate documents. The difficulty here is in
developing something where your algorithm can't be reversed or guessed
at.
I hope that helps,
Colin
On Tuesday, October 5, 2004, at 11:46 AM, Janice Cheung wrote:
Hi David!
I have two separate projects - the first is a Profile system where
a user logs in to edit personal (HR)
information and retrieve certificates via hyperlinks. These
hyperlinks connect to a second project,
a PDF certificate generator that creates PDF files based on
certificate primary keys.
The certificate generator initially retrieved one type of report
for one specific exam, but we have scaled it to a higher level, to
encompass different institutions. The security wasn't an
issue before, but now we wouldn't like any staff members who have
wayward intentions to punch
in random (but existing) primary keys and get certificates that do
not rightfully belong to them.
The certificate generator project requires this one vital piece of
information (the primary key) for
PDF creation. These PDF certificate are created/downloaded onto a
user's computer .. not onto
the server itself for downloading. Basically we would like to
prevent nefarious folks (with way
too much time on their hands) from guessing the names and primary
keys of other people's reports.
Thanks for writing me back! I appreciate your input.
Best Regards,
Janice :)
David LeBer wrote:
On Oct 5, 2004, at 10:48 AM, Janice Cheung wrote:
Greetings!
Is anyone aware of a method using Direct Actions, that actually
suppresses the primary keys
in the URL?
My educational institution is issuing
certifications/certificates, which I am generating on the
fly as database driven PDF reports.
For example, upon submission (via a hyperlink or WOActive image
button), I ultimately arrive
at a page similar to this:
http://hostname/WebObjects/projectName.woa/wa/viewReport?cPk=n
'n' is equal to certification Primary key (cPk)
Instead of this URL, I would like something somewhat more secure:
http://hostname/WebObjects/ProjectName.woa/wa/
viewReport=NowYouWillNeverFindThisUrlAgainMuhaha
Does anyone know how to implement this? I am in dire need of
some help...
Any advice or guidance would be greatly appreciated!
What is it that you are trying to achieve Janice?
A direct action is going to give you a reproducible URL. That is its
job. To do that you need to pass it the parameters it needs to
perform its task (in this case find the report). If you want a
dynamic URL, then maybe a component action would be better (linked
to an authentication mechanism perhaps).
So, are you looking to obfuscate the search criteria so that someone
cannot guess the name of other reports, or is there something else
going on?
The appropriate solution will depend on your requirements. Off the
top of my head, here are a couple ideas:
- Give the report a random "code" when generated and use that to
retrieve.
- Give the report a date code when generated and only allow it to be
retrieved for a short window.
- Make the report retrieval require authentication and only vend the
appropriate report.
- Vend the report into a temporary directory, and delete after
viewing.
;david
--
David LeBer
Codebase Software Systems
site: http://www.codebase.ca
blog: http://david.codebase.ca
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
---
Colin Clark
Dynamic Web and Database Development Lead,
Resource Centre for Academic Technology,
University of Toronto
(416) 946-7592 / email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden