Application to handle form approval

Hopefully this is the right place for this question.

I have done a fair amount of research and yet to find anything that matches what I want. What I’m envisioning is the following. Let me know if any of you know of a program that will do what I want.

anom user -> fills out form ->
email gets sent to admin saying xyz has filled out form abc with links to approve/disapprove request.

admin can also login and edit form and resent results to original submitter. Also once the admin approves/disapproves request the original submitter gets an approve/disapprove email.

and you can search by date submitted, specific project/form, status of request(submitted, approved, disapproved).

any ideas all on where I could find this? I started to look into drupal with workflows and actions but it just doesn’t flow right for this .

I don’t see why you would hash(formId+admin-e-mail+submissiontime) and use that, why not generate a random hash alltogether? That’s way harder to hack because (1) it isn’t based on a known scheme like in your example. When a hacker finds the scheme the whole security is down the drain. With random hashes this doesn’t happen, (2) random hashes have way more possibilities than the hashes created by the scheme you suggested, and thus have higher entropy, which makes them harder to guess than your schemed hashes.

Chronicle, I’d provide a different piece of advice for user authentication.

Instead of requiring a username/password for your administrator, what I’d suggest is this:

  1. Store the results of the sent form in the database.
  2. Create a unique identifier for that form submission in the database.
  3. Store the time the form was submitted.
  4. Hash the combination of the form ID, the admin’s email address and the submission time together, and store that in a lookup table in the database which correlates back to the form submission ID.
  5. Pass this hash as a GET parameter via the email.

This obviously isn’t airtight security, but it doesn’t require that your admin know a username/password, and it doesn’t require any session handling. It allows a simple database lookup on the destination page, and you’ll have to do very little handling or securing in order to display the information for the admin.

I think SituationSoap’s idea was to create a kind of automatic password that the application would generate and which the email link would automatically provide back to the application. :slight_smile:

Between a constructed hash and a random hash, a random hash provides a more secure key for the reasons outlined, and it’s also easier to generate since most languages have utility functions to generate random keys because they’re so fundamental to security (just like this situation).

I can see a solution like this in certain circumstances. If you had an admin with access to email but not the internet, this would definitely be the way to go. The architecture of this portion of the workflow is basically two step. 1) Users fill out form; the data entered is stored in the database and then sent by email to the admin. 2) Admin processes the request.

This variation using a random hash on the link does a reasonable job of securing step two. Whether the email is automating the process or the admin is browsing to the application, there is a webpage on the server which processes the work. If someone besides the admin connects to that URL, you don’t want them to have access so you require authorization. One way to authorize is to have the admin log in, another way to to provide login credentials automatically in the HTTP request (in this case as parameters in the URL, a random hash). So that’s sensible.

The concern about this solution is in step 1. First, email is fundamentally insecure, and two, you’re putting the credentials on the web. Because email is insecure, it’s possible that someone can get their hands on it and simply spoof the server using the link. If they use the email link before the admin, they will have control over what happens. Second, even if you exercise some kind of encryption on the email message at the server (which then assumes the admin unscrambles it on the other end), the credentials have been posted on the web. You would NOT want to use this solution to pass a username and password even in an encrypted state. In this respect, the using a random hash as a one-time key offers superior security. The length of time the link is good for is only as long as it takes the admin to use it. You’d want to program this so the admin can click the link to post a (dis)approval and then erase the key from the database. That way if the key is broken in the future, it no longer has any value. The one-time nature of the key provides higher security when compared credentials that were useful over an extended period of time.

That said, if it’s worth messing with security at all (and on some projects there isn’t), most of the time I would prefer the relative ease and high security value of entering a username and password into the website.

Sounds like a custom script would handle this with no prob. Should be easy enough to program.

I agree CMS / structured frameworks have flexibility issues if they’re providing more than utility functions. You’ve broken out each step in the workflow nicely, this is basically a verbal flowchart right there. I don’t think any particular step should be that hard to deal with.

Step 1 is a webpage with form. Setting up the form is just some basic HTML form components. On the backside, you then check for postback and to see if the postback matches the value of your submit button. The more fields you have the more variables you have to dig out of the HTTP request that’s sent by the postback, but it’s straightforward to grab them (just repetitive). Once you have all that data, you email it to the admin. For ease, I would at minimum break the email out into a separate class, one because otherwise you will have a lot of code in there (if the form is long the length of the script may be a huge headache anyway). Plus, email is something you may use in a number of places, (like step 2!) so it would be good to have it broken out as an independent modules which handles all email.

One note about security. If these requests are not that important, then it may not be a problem, but processing the request from the email is a very insecure thing to do. I would recommend having one link to an admin page in step 2. That means the admin won’t be able to complete work from an email client, they’ll need to log in to the website, but unless security is not on your radar, this is a much better architecture.

This will be page 2 of the application, an administration page. At this point, you will need a database to store information, though if you’re smart you’ll probably already have saved the information for the email to the database from page 1. The main purpose of page 2 is set one of three radio buttons, it sounds like “approve”, “disapprove”, or “edit”. Selecting edit means you’ll pay attention to whatever additional form controls you need to specifying the edits that need to be made, and the script will also send the email to the original submitter letting them know which of the options was chosen.

Now, I wouldn’t recommend a standard login, since your website looks like it can probably do without them. At the bottom have a “confirm action” form for the admin. Accept their username and password on postback, take the username to hit the database and recover their hashed password from the DB, then hash the password they provided and see if the two hashes match. If they do, process whatever action they’ve requested, and if not ignore their request. By changing the “login” to a “confirmation” form at the bottom of the page (sort of like providing a signature) you’ll eliminate the need to handle sessions.

The authorization process I’ve outlined is pretty straightforward and there are excellent functions to help manage most of that. Even so, the security is all being handled directly on the server so it’s very secure. The only additional recommendation I would make to that is using a regex whitelist on the user input to prevent malicious scripts / SQL injection attacks, etc.

If you do login, you’ll need to start, track, and close sessions which is a lot more work, and it’s fundamentally insecure (better than email, but not by much) and require a lot of custom security coding. If you can avoid it, it will eliminate a lot of headaches in coding. You’re just asking the admin to submit their username and password for each set of actions. And it sounds like you’re only running one set of actions, so that makes sense.

This could be part of the admin page 2, or you might make it a viewer page of it’s own. Either way the important thing is whether or not it needs to be private vs. public and whether you’re viewing the results vs. making changes. If it needs to stay private, the admin will need to provide a log in before you let them see it. It’s now possible you may be asking them to “log in” twice, once to process the initial request that arrived by email, and a second time to monitor everything. If it can be public, then you just spit the data out to the webpage (like a report). Also, if it’s just a viewer then you can’t interact with the data, just look at it. That’s a pretty low level threat securitywise. If on the other hand this is an active management panel where the admin will be making lots of requests, then it’s probably prohibitively difficult to sign in for each management action. You’ll probably have to take the hit and build sessions in with the custom security. (Note that while PHP has a $SESSION, the only thing you ever want to stick in it (because it’s so insecure) is a custom session ID that you’ve stored in the DB and associated with a particular user (so when you dig the custom session variable out, you can tell which user you have). Then just close the session as soon as is reasonable for the application, ie erase the custom session ID from the database (usually from 1-2 minutes, anything shorter is overkill, to 1-2 hours, anything longer is pushing it).