[FX.php List] Disallowing access thru modifying url?
DC
dan.cynosure at dbmscan.com
Thu Apr 27 11:49:32 MDT 2006
I've got to stop posting to the FX list and get back to work...
But, I couldn't resist.
This seems an overly complicated way to obfuscate links if obfuscating
links is all you want to do.
The only benefit I can see in building a second layer of database tables
to code links is for the ability to 'expire' them (as was mentioned). Is
there some side benefit I am missing? But, you could also do this simply
by using PHP to encode an expiration date in all of your links.
The only reasons you'd use a table to store exipiration dates for links
is if you wanted to be able to modify the expiration date without
modifying the link or if you had relationships to a users table from the
link mapper table and you needed to keep all the coded links matched up
with a certain user.
This seems like growing a knotty thornbush at your front door to keep
people from looking in the window. Everytime you want to expand or
modify your database tables you'll have to modify two tables.
Maintaining and expanding it is going to be a drain.
My advice is don't build a second layer of database tables. Just hide
the links as they are created in PHP using a simple PHP encoder/decoder.
dan
Steve Winter had written:
> 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
>
>
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>
More information about the FX.php_List
mailing list