S Brown
|
| Posted: 02/05/2002, 9:55 PM |
|
If I've examined the cc output code correctly, a "GRID" is not actually a "form" it is created in the code as a table. I guess this is the reason that all movement from a GRID to a RECORD (form) uses the <a href URL to pass parameters to the RECORD with transit parameters sent in the browser address bar.
Trying to come up with a way to overcome parameters in the address bar.
|
|
|
 |
Andrew B
|
| Posted: 02/05/2002, 11:51 PM |
|
Well, this problem has plagued web guys and gals since the dawn of notepad. No real way around it. Sorry.
If there is something that vital, stick it in the session. Do the proper security checks on load of the page. Yes it is more work, but if you have sql server and can write basic stored procedures, it is quite easy. Also, I have found that most of my custom permission checking (can that guy edit that user) can be accessed through DLookups.
Just remember to stick most of the important fields that you will use for security into the session on login.
|
|
|
|
S. Brown
|
| Posted: 02/06/2002, 12:15 AM |
|
Don't session variables require "Cookies" to be allowed (set in the visitor's browser)?
|
|
|
|
S. Brown
|
| Posted: 02/06/2002, 12:34 AM |
|
It's my understanding that by using "POST" to transfer parameters, parameters are passed in the page header, not the URL as with GET which shows everything in the browser address bar! And, use of GET can restrict the amount of information that one can transfer (based on the browser in use), not so with POST. <SB
|
|
|
|
Nicole
|
| Posted: 02/06/2002, 5:48 AM |
|
Brown,
add <form> and </form> tags in Grid form header and footer, so you'll get the form and set data transfer method to POST.
|
|
|
|
Andrew B
|
| Posted: 02/07/2002, 8:15 PM |
|
Yes, cookies are required. The cookie stores the session key which lets IIS access that particular user's session values. Once again, there is really no way around this. HTTP is stateless, really, and each connection is essentially 'new'. In this case at least you are not storing the values in the cookie where they can be read at a later date. Also, these cookies expire as soon as the session times out, i think.
As for forms, yes post does not limit data length, but then you shouldn't really be passing that much data unless you are doing an update, where it can't be avoided. The problem with forms is that you need to create them on the fly and then have JS submit them for you, unless you want the user to have to press a button. Possible, but needlessly diffucult.
In either case (cookies/forms) the data is easily available to the user. For forms, juse view source, and you can simply open up the cookies with a standard text editor (if they aren't encrypted.)
As for wrapping the grid in <form> tags, how does that put the URL var's into the form? If you click the url, it goes there, but it does not submit the form. If it did submit the form, you would have to figure out a way to create the proper form elements so it would be recognized on the next page.
AFIAK, you were asking about the redirection. I think the best way would be to stick the vars into the session in a custom CheckSecurity() function, and then modify 'login' to read those and not the param values. This could probably be accomplished pretty simply in the events for the login form.
|
|
|
|
|
