Thread

Eh, ok.  I’m not working on this now, but am thinking of a project that would need something like what you initially described.  What did you come up with?

So far nothing actually. I took Derek’s stuff and implemented a little test thing, but we’re working on other priorities at the moment.

A flag like I described is most useful for social media sites. Is that what you’re building?

Hey Derek: I was looking at your code again and realizing that, with your method of accessing the DB directly like that we could enable a lot of quick modifications without stepping through the EE form hoops. My big concern is whether that’s secure or not, as in, couldn’t someone open up a page, look at the javascript’s target/return file, then hit that file over and over while changing the entry_id (that I imagine would be passed as a segment). Is there any way to make it more secure? Am I being paranoid?

Depends on what type of security and restrictions you need.  From your description, it didn’t sound like an issue as you wanted anyone to be able to change the status, correct?  Obfuscation methods might help (encrypted form, encrypted javascript), but in the end are not real security.

True true, although I’m not sure how to do an encrypted form. It would be nice to know how to utilize EE’s form handling to do this though.

The great thing about using urls to pass entry_ids and such is the versatility (it’s RESTful, no?). It’s just not very secure if a user can start swapping out url segments.

$FNS->form_declaration($data); combined with the Form Tag Encoder extension can take care of that for you.

Cool, thanks for the heads up!