[FX.php List] Disallowing access thru modifying url?
Joel Shapiro
jsfmp at earthlink.net
Thu Apr 27 15:02:35 MDT 2006
Thanks very much, Steve, that does all make sense and I appreciate
your time.
I am inclined to think, though, that for my current needs (to
obfuscate the links, as Dan correctly puts it) this would add quite a
bit of extra bulk and overhead to the project. I'm guessing that in
your solution where you do this, you're doing more than just
obfuscating the links.
And thanks Dan for taking the extra time to post your response ;)
Best,
-Joel
On Apr 27, 2006, at 10:49 AM, DC wrote:
> 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
> _______________________________________________
> 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