[FX.php List] Disallowing access thru modifying url?

[Steve Winter]

Joel,

A refresh wouldn't be necessary, depending on how you did it... you could
either;
 a. simply have the page ids in your database with long an complicated
non-sequential 'names' which would potentially be a bit of a pain to maintain.
 b. have an 'intermediate' db (which I think is what Hal was really
suggesting, and the way that I do it) which created a link that said, if
the user asks for id=gnksjen68en80g4ekjn5 in recordRequest.fp7, then that
really means id=101 in content.fp7. Then in your php page you do two calls
  to fx.php; (off the top of my head code, not tested)
  $whichRecordQuery = new FX($serverIP, $serverPort, $serverType);
  $whichRecordQuery->SetDBData("recordRequest", "web");
  $whichRecordQuery->AddDBParam("id",$_REQUEST['id']);
  $whichRecordData=$whichRecordQuery->FMFind();
  $whichRecordKey=key($whichRecordData);
then in the same php page you make the next call to your 'real' content db
  $dataQuery = new FX($serverIP, $serverPort, $serverType);
  $dataQuery->SetDBData("content", "web");
 
$dataQuery->AddDBParam("id",$whichRecordData['data'][$whichRecordKey]['id][0]);
  $dataData=$dataQuery->FMFind();

  Page content goes here...

 c. finally you could use FMP to make the association for you, so you
could use only the first FMP call above, to the relatedRecords db, then
display the content on the page using the fileds from the related record
in FMP. This would mean only one call to FMP, which would make things a
little speedier if you were on a high demand site...it may however make
creating some related content further down more complex...

Hope this makes sense...

Cheers
Steve


> Thanks for the input, Steve.
> I actually may not need to put together the updated solution together  
> now until this summer or fall, so I'll look into this as well.
> Hal says the link "would find the RecordsRequest where it could find  
> the real record id and then go on to find the record of interest."   
> Would this be just a second query on the php page?  Or how would this  
> work?  (I'd imagine a refresh would be unnecessarily slow)
> 
> Thanks,
> -Joel
> 
> On Apr 26, 2006, at 3:36 PM, Steve Winter wrote:
> 
> > Joel,
> >
> > I think that this solution which Hal has provided is an excellent  
> > one for
> > your needs, and is the way that I handle a very similar situation...
> >
> > One thing that you might like to think about, Hal suggested;
> >> - You could also add a RecordsRequest expiration timestamp.
> >> After a certain amount of time old RecordsRequest could be
> >> deleted.
> > If you do do this, it does mean that legitimate users can't  
> > bookmark a page
> > to return to that page of your site another day. While this may not  
> > be a
> > problem in your situation, it did cause me problems with one  
> > solution I
> > developed...
> >
> > Cheers
> > Steve
> >
> >
> >> On Apr 24, 2006, at 1:28 PM, Joel Shapiro wrote:
> >>
> >>> What ways are there to limit record access to *only* clicked-on
> >> links?
> >>>
> >>> When I get a list of records, clicking on any one of them links to
> >>> their respective url, e.g.:
> >>> http://127.0.0.1/page.php?recid=1234
> >>
> >> You might be able to deal with this in the same way some credit card
> >> companies generate temporary credit card numbers for online  
> >> purchases.
> >>
> >> While generating the page for the user, add records to a
> >> RecordsRequest table which act as an alias to the real record like  
> >> so:
> >>
> >> http://127.0.0.1/page.php?recreq=394598443986543394598443986543
> >> http://127.0.0.1/page.php?recreq=239423048786676239423048786676
> >> http://127.0.0.1/page.php?recreq=349349349766688349349349766688
> >>
> >> - When they click on the the link, it would find the RecordsRequest
> >> where it could find the real record id and then go on to find the
> >> record of interest.
> >> - If you made the recreq big enough it would be hard to guess one
> >> that existed. Generating it could be as easy as choosing a random
> >> single digit number/letter and appending twenty of them or so. Just
> >> make sure the generated number doesn't already exist.
> >> - You could also add a RecordsRequest expiration timestamp. After a
> >> certain amount of time old RecordsRequest could be deleted.
> >>
> >> Does this make sense? It would add a layer of complexity, but not
> too
> >> much...
> >>
> >> Hal
> >> -- 
> >> Hal Gumbert  <hal at macfl.com> or <hal at mac.com>
> >> MacFL        <http://www.macfl.com>
> >>
> >> - FileMaker 7 Certified Developer & FileMaker 8 Certified Developer
> >> - Apple Certified ACTC 10.1,  ACHDS 10.3, ACHDS 10.4
> >>
> >>
> >> _______________________________________________
> >> FX.php_List mailing list
> >> FX.php_List at mail.iviking.org
> >> http://www.iviking.org/mailman/listinfo/fx.php_list
> >
> >
> > _______________________________________________
> > FX.php_List mailing list
> > FX.php_List at mail.iviking.org
> > http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list