Thread: [Secureideas-base-devel] Multiple BASE sessions at once
Brought to you by:
secureideas,
sinukas
From: Micah G. <mi...@on...> - 2008-10-27 18:18:10
|
Is there an interest in this? I'm going to make a patch for my version, but if there is an interest, I will submit it to the project. -- Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Randal T. R. <ra...@pr...> - 2008-10-27 18:52:59
|
On Mon, October 27, 2008 2:14 pm, Micah Gersten wrote: > Is there an interest in this? I'm going to make a patch for my version, > but if there is an interest, I will submit it to the project. Yes :-) Randy |
From: Kevin J. <ke...@in...> - 2008-10-27 19:08:52
Attachments:
PGP.sig
|
There has been interest in the past. If you are going to generate the patch, please submit and at the least we can include it as an extra. Kevin Kevin Johnson Senior Security Analyst InGuardians, Inc. office: 202.448.8958 cell: 904.403.8024 On Oct 27, 2008, at 2:14 PM, Micah Gersten wrote: > Is there an interest in this? I'm going to make a patch for my > version, > but if there is an interest, I will submit it to the project. > > -- > > > Thank you, > Micah Gersten > onShore Networks > Internal Developer > http://www.onshore.com > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Secureideas-base-devel mailing list > Sec...@li... > https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel > |
From: Michael S. <ms...@ma...> - 2008-10-28 21:19:20
|
On Mon, Oct 27, 2008 at 03:08:38PM -0400, you wrote: >There has been interest in the past. If you are going to generate the >patch, please submit and at the least we can include it as an extra. Even better would be to stop storing so much state as session variables, and start exposing it as GET parameters (so we could use the back button). Mike Stone |
From: Micah G. <mi...@on...> - 2008-10-28 21:26:58
|
Michael Stone wrote: > On Mon, Oct 27, 2008 at 03:08:38PM -0400, you wrote: > >> There has been interest in the past. If you are going to generate the >> patch, please submit and at the least we can include it as an extra. >> > > Even better would be to stop storing so much state as session variables, > and start exposing it as GET parameters (so we could use the back > button). > > Mike Stone > > I disagree. It's a lot cleaner to store things in the session. In what case would you want to use the back button? Maybe there's a better alternative than extremely long URLs. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Michael S. <ms...@ma...> - 2008-10-29 00:54:54
|
On Tue, Oct 28, 2008 at 07:39:45PM -0500, Micah Gersten wrote: >Here's the best argument I can think of. Hopefully this will end, then. >Passing parameters in the URL >is asking for users to start modifying them to see what funny stuff can >happen. The less they know of the inner workings of the app, the better. This is an open source app--what's to hide? And they can do the same thing with POST parameters; there are even GUIs to let them point and drool if they don't want to do it by hand. Note that this futile effort to hide things greatly complicates the ability of the legitimate users to use productivity enhancements like bookmark shortcuts Mike Stone |
From: Micah G. <mi...@on...> - 2008-10-29 01:00:17
|
Michael Stone wrote: > On Tue, Oct 28, 2008 at 07:39:45PM -0500, Micah Gersten wrote: >> Passing parameters in the URL >> is asking for users to start modifying them to see what funny stuff can >> happen. The less they know of the inner workings of the app, the >> better. > > This is an open source app--what's to hide? And they can do the same > thing with POST parameters; there are even GUIs to let them point and > drool if they don't want to do it by hand. > > Note that this futile effort to hide things greatly complicates the > ability of the legitimate users to use productivity enhancements like > bookmark shortcuts > Mike Stone It might be open source, but not everyone is a programmer that can read the code. For every variable you put in the get parameter, you have another thing the user can try to play with. Also, I don't believe in bookmarking within a DB app especially with long get parameters as the logic of the program and variable names can change and break everything. You really tie the hands of developers when you show that much data. Wait, I know what your going to say...once you publish a long URL like that, it has to work always from a bookmark, am I right? That's the exact problem... Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Micah G. <mi...@on...> - 2008-10-29 20:41:51
Attachments:
base_conf.php.dist.diff.txt
|
Here's the patch. Can someone put it in CVS? Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Kevin Johnson wrote: > There has been interest in the past. If you are going to generate the > patch, please submit and at the least we can include it as an extra. > > Kevin > > Kevin Johnson > Senior Security Analyst > InGuardians, Inc. > office: 202.448.8958 > cell: 904.403.8024 > > On Oct 27, 2008, at 2:14 PM, Micah Gersten wrote: > >> Is there an interest in this? I'm going to make a patch for my version, >> but if there is an interest, I will submit it to the project. >> >> -- >> >> >> Thank you, >> Micah Gersten >> onShore Networks >> Internal Developer >> http://www.onshore.com >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> <http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> _______________________________________________ >> Secureideas-base-devel mailing list >> Sec...@li... >> https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel >> > |
From: Micah G. <mi...@on...> - 2009-07-05 03:07:35
|
I had a problem if there was a period in $BASE_installID. I believe I corrected this with another patch. I'll send a new patch tomorrow when I get in the office. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Randal T. Rioux wrote: > Micah Gersten wrote: >> Here's the patch. Can someone put it in CVS? > > I added this to the base_conf.php.dist file in CVS. Please test - > seems to work fine on my systems. > > Thanks, > Randy |
From: Micah G. <mi...@on...> - 2009-07-06 04:39:25
|
I never did actually fix the problem, I just worked around it. The solution is to change the replace to replace any non-alphanum character with an underscore. I just don't have time to fix it right now. When I get a chance, I will. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Micah Gersten wrote: > I had a problem if there was a period in $BASE_installID. I believe I > corrected this with another patch. I'll send a new patch tomorrow when > I get in the office. > > Thank you, > Micah Gersten > onShore Networks > Internal Developer > http://www.onshore.com > > > > Randal T. Rioux wrote: > >> Micah Gersten wrote: >> >>> Here's the patch. Can someone put it in CVS? >>> >> I added this to the base_conf.php.dist file in CVS. Please test - >> seems to work fine on my systems. >> >> Thanks, >> Randy >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Secureideas-base-devel mailing list > Sec...@li... > https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel > |
From: Randal T. R. <ra...@pr...> - 2009-07-04 05:35:03
|
Micah Gersten wrote: > Here's the patch. Can someone put it in CVS? I added this to the base_conf.php.dist file in CVS. Please test - seems to work fine on my systems. Thanks, Randy |
From: Kevin J. <ke...@in...> - 2009-07-04 13:22:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 4, 2009, at 1:34 AM, Randal T. Rioux wrote: > Micah Gersten wrote: >> Here's the patch. Can someone put it in CVS? > > I added this to the base_conf.php.dist file in CVS. Please test - > seems > to work fine on my systems. Thanks! I will try to test it out today. Kevin Kevin Johnson Senior Security Analyst InGuardians, Inc. office: 202.448.8958 cell: 904.403.8024 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpPV4gACgkQGDcWptZ2zmQ8KgCeJPM4Wt/8RNaNp6qcSrbUAZLR pzsAoODlilIF9UAgXWlOgHX3N5RA2HF3 =0Q3x -----END PGP SIGNATURE----- |
From: Michael S. <ms...@ma...> - 2008-10-28 22:42:40
|
On Tue, Oct 28, 2008 at 04:26:46PM -0500, Micah Gersten wrote: >I disagree. It's a lot cleaner to store things in the session. Cleaner for who? Certainly not for the user--because it breaks functionality like "back" or "click on something after coming back from lunch"--and certainly not for the developer, because it leads to bizarre things like needing to develop workarounds for the fact that the session is holding a bunch of state that it shouldn't be. >In what case would you want to use the back button? Any time I want to go back to the last page? Having a stupid "back" link is ridiculously less functional than the big honkin' "back" button or any of the other ways provided by the browser to go back. >Maybe there's a better alternative than extremely long URLs. Who cares how long the URL is? I care far more about functionality like "can I bookmark this" than whether it's long. Check out google--they've become very popular even though their search URLs are long. Mike Stone |
From: Micah G. <mi...@on...> - 2008-10-28 21:40:24
|
Michael Stone wrote: > On Tue, Oct 28, 2008 at 04:26:46PM -0500, Micah Gersten wrote: >> I disagree. It's a lot cleaner to store things in the session. > > Cleaner for who? Certainly not for the user--because it breaks > functionality like "back" or "click on something after coming back > from lunch"--and certainly not for the developer, because it leads to > bizarre things like needing to develop workarounds for the fact that > the session is holding a bunch of state that it shouldn't be. It's certainly more secure to store things in the session than in URLs. Also, if you have trouble of sessions timing out during your lunch break, just increase the timeout. >> In what case would you want to use the back button? > > Any time I want to go back to the last page? Having a stupid "back" > link is ridiculously less functional than the big honkin' "back" > button or any of the other ways provided by the browser to go back. The back button is a carryover from the old days when everything was static content. Also, depending on how stuff is stored in the session, the back button could work just fine. The question comes back to, what are you backing up to? >> Maybe there's a better alternative than extremely long URLs. > > Who cares how long the URL is? I care far more about functionality > like "can I bookmark this" than whether it's long. Check out > google--they've become very popular even though their search URLs are > long. > > Mike Stone I find it very annoying when I see extremely long URLs in the location bar. If you're talking about needing to mark favorite queries, maybe that's a feature request. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Michael S. <ms...@ma...> - 2008-10-29 01:06:21
|
On Tue, Oct 28, 2008 at 08:00:08PM -0500, Micah Gersten wrote: >It might be open source, but not everyone is a programmer that can read >the code. For every variable you put in the get parameter, you have >another thing the user can try to play with. Waah. That's what input validation is for (and yes, you really do have to do that, even if you can't figure out how to play with the input values). >Also, I don't believe in bookmarking within a DB app especially with >long get parameters as the logic of the program and variable names can >change and break everything. You really tie the hands of developers >when you show that much data. Wait, I know what your going to >say...once you publish a long URL like that, it has to work always from >a bookmark, am I right? That's the exact problem... Yup, I'm putting the interests of the users ahead of the baseless fear of a developer. Stupid me. P.S. If you have a sensible design, you don't have to worry much about dramatic changes breaking things. People have been creating interfaces for a long time, it's not rocket science. (And creating versioned interfaces is also a solved problem...) Mike Stone |
From: Randal T. R. <ra...@pr...> - 2008-10-29 08:40:39
|
Crap. I clicked "back" while using my webmail client and lost my original message. I'm gonna top-post this and state a point or two. URL data should not be of concern. If you are on a network where you are worried about such info, you've setup your IDS analysis environment all wrong. I, as do most "users," instinctively click the back button/arrow/etc. when navigating. I've punched many a monitor when sifting through BASE data and slipping. If URL strings are not an option, session data can be designed to store recent selections. If the user clicks back, the first PHP line should check this session for such data, and utilize that for page generation. The design just needs to be thought through. This is one field where intelligent design makes sense. Randy On Tue, October 28, 2008 9:06 pm, Michael Stone wrote: > On Tue, Oct 28, 2008 at 08:00:08PM -0500, Micah Gersten wrote: >> It might be open source, but not everyone is a programmer that can read >> the code. For every variable you put in the get parameter, you have >> another thing the user can try to play with. > > Waah. That's what input validation is for (and yes, you really do have to > do that, even if you can't figure out how to play with the input values). > > >> Also, I don't believe in bookmarking within a DB app especially with >> long get parameters as the logic of the program and variable names can >> change and break everything. You really tie the hands of developers >> when you show that much data. Wait, I know what your going to >> say...once you publish a long URL like that, it has to work always from >> a bookmark, am I right? That's the exact problem... > > Yup, I'm putting the interests of the users ahead of the baseless fear of > a developer. Stupid me. > > P.S. If you have a sensible design, you don't have to worry much about > dramatic changes breaking things. People have been creating interfaces > for a long time, it's not rocket science. (And creating versioned > interfaces is also a solved problem...) > > Mike Stone > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & > win great prizes Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Secureideas-base-devel > mailing list Sec...@li... > https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel > |
From: Micah G. <mi...@on...> - 2008-10-29 00:20:41
|
Michael Stone wrote: > On Tue, Oct 28, 2008 at 05:13:47PM -0500, Micah Gersten wrote: >> The problem is that it's more overhead in processing to have to >> reprocess all the GET parameters after every page load instead of using >> the session store that is loaded and you can either use the data or not. > > If the "processing overhead" of parsing some query parameters is a > significant fraction of the load on your system, you've got a really > crazy (broken) setup. > > Mike Stone Yes, but why would you want to process the same data more than once? Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Micah G. <mi...@on...> - 2008-10-29 16:39:36
|
GaRaGeD Style wrote: > On Wed, Oct 29, 2008 at 11:17 AM, Micah Gersten <mi...@on...> wrote:It seems that there are very few forms in BASE. So you just store the > data related to the last search in the session. That should take care of > most of the back button problems. > > > Thats a oversimplification of the problem, the idea of the > implementation in base is that you can go back multiple times, not > just the last visited page. > > Regards > Max > > Yes, but most of the pages could be generated with 1 or 2 get parameters which would be in the history. The search is the larger problem. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |
From: Kevin J. <ke...@in...> - 2008-10-29 13:34:31
Attachments:
PGP.sig
|
I apologize for the delay in me joining this conversation, I am onsite at a client doing a pen test and haven't had time. I agree 200% that the back button on the page needs to disappear and the browser button needs to work. But with the current design we have inherited, it is not a simple change. If you look back through the CVS or mailing list you will see that we attempted to move to a better system. BASE broke and broke bad. This is why we need to rewrite for Second Base. The final solution will not be able to completely use the URL, as BASE passes more information in some requests then the URL can take. But we should use it where possible for the "bookmarkatability" (yes I made up that word) it provides the user. As to the security concerns, as a web pen tester, the use or lack of use of the URL should not make the site less secure, in regards to injection, as the system should be doing sane input validation before EVER using the input. (I know about the other issues with URLs but am not addressing them here.) Kevin Kevin Johnson Senior Security Analyst InGuardians, Inc. office: 202.448.8958 cell: 904.403.8024 On Oct 29, 2008, at 4:35 AM, Randal T. Rioux wrote: > Crap. I clicked "back" while using my webmail client and lost my > original > message. I'm gonna top-post this and state a point or two. > > URL data should not be of concern. If you are on a network where you > are > worried about such info, you've setup your IDS analysis environment > all > wrong. > > I, as do most "users," instinctively click the back button/arrow/ > etc. when > navigating. I've punched many a monitor when sifting through BASE > data and > slipping. If URL strings are not an option, session data can be > designed > to store recent selections. If the user clicks back, the first PHP > line > should check this session for such data, and utilize that for page > generation. The design just needs to be thought through. This is one > field > where intelligent design makes sense. > > Randy > > > On Tue, October 28, 2008 9:06 pm, Michael Stone wrote: >> On Tue, Oct 28, 2008 at 08:00:08PM -0500, Micah Gersten wrote: >>> It might be open source, but not everyone is a programmer that can >>> read >>> the code. For every variable you put in the get parameter, you have >>> another thing the user can try to play with. >> >> Waah. That's what input validation is for (and yes, you really do >> have to >> do that, even if you can't figure out how to play with the input >> values). >> >> >>> Also, I don't believe in bookmarking within a DB app especially with >>> long get parameters as the logic of the program and variable names >>> can >>> change and break everything. You really tie the hands of developers >>> when you show that much data. Wait, I know what your going to >>> say...once you publish a long URL like that, it has to work always >>> from >>> a bookmark, am I right? That's the exact problem... >> >> Yup, I'm putting the interests of the users ahead of the baseless >> fear of >> a developer. Stupid me. >> >> P.S. If you have a sensible design, you don't have to worry much >> about >> dramatic changes breaking things. People have been creating >> interfaces >> for a long time, it's not rocket science. (And creating versioned >> interfaces is also a solved problem...) >> >> Mike Stone >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge Build the coolest Linux based applications with Moblin >> SDK & >> win great prizes Grand prize is a trip for two to an Open Source >> event >> anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ Secureideas-base- >> devel >> mailing list Sec...@li... >> https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel >> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Secureideas-base-devel mailing list > Sec...@li... > https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel > |
From: Micah G. <mi...@on...> - 2008-10-29 16:17:15
|
It seems that there are very few forms in BASE. So you just store the data related to the last search in the session. That should take care of most of the back button problems. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Kevin Johnson wrote: > I apologize for the delay in me joining this conversation, I am onsite > at a client doing a pen test and haven't had time. > > I agree 200% that the back button on the page needs to disappear and > the browser button needs to work. But with the current design we have > inherited, it is not a simple change. If you look back through the > CVS or mailing list you will see that we attempted to move to a better > system. BASE broke and broke bad. > > This is why we need to rewrite for Second Base. > > The final solution will not be able to completely use the URL, as BASE > passes more information in some requests then the URL can take. But > we should use it where possible for the "bookmarkatability" (yes I > made up that word) it provides the user. > > As to the security concerns, as a web pen tester, the use or lack of > use of the URL should not make the site less secure, in regards to > injection, as the system should be doing sane input validation before > EVER using the input. (I know about the other issues with URLs but am > not addressing them here.) > > Kevin > > Kevin Johnson > Senior Security Analyst > InGuardians, Inc. > office: 202.448.8958 > cell: 904.403.8024 > > On Oct 29, 2008, at 4:35 AM, Randal T. Rioux wrote: > >> Crap. I clicked "back" while using my webmail client and lost my original >> message. I'm gonna top-post this and state a point or two. >> >> URL data should not be of concern. If you are on a network where you are >> worried about such info, you've setup your IDS analysis environment all >> wrong. >> >> I, as do most "users," instinctively click the back button/arrow/etc. >> when >> navigating. I've punched many a monitor when sifting through BASE >> data and >> slipping. If URL strings are not an option, session data can be designed >> to store recent selections. If the user clicks back, the first PHP line >> should check this session for such data, and utilize that for page >> generation. The design just needs to be thought through. This is one >> field >> where intelligent design makes sense. >> >> Randy >> >> >> On Tue, October 28, 2008 9:06 pm, Michael Stone wrote: >>> On Tue, Oct 28, 2008 at 08:00:08PM -0500, Micah Gersten wrote: >>>> It might be open source, but not everyone is a programmer that can read >>>> the code. For every variable you put in the get parameter, you have >>>> another thing the user can try to play with. >>> >>> Waah. That's what input validation is for (and yes, you really do >>> have to >>> do that, even if you can't figure out how to play with the input >>> values). >>> >>> >>>> Also, I don't believe in bookmarking within a DB app especially with >>>> long get parameters as the logic of the program and variable names can >>>> change and break everything. You really tie the hands of developers >>>> when you show that much data. Wait, I know what your going to >>>> say...once you publish a long URL like that, it has to work always from >>>> a bookmark, am I right? That's the exact problem... >>> >>> Yup, I'm putting the interests of the users ahead of the baseless >>> fear of >>> a developer. Stupid me. >>> >>> P.S. If you have a sensible design, you don't have to worry much about >>> dramatic changes breaking things. People have been creating interfaces >>> for a long time, it's not rocket science. (And creating versioned >>> interfaces is also a solved problem...) >>> >>> Mike Stone >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge Build the coolest Linux based applications with Moblin SDK & >>> win great prizes Grand prize is a trip for two to an Open Source event >>> anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> <http://moblin-contest.org/redirect.php?banner_id=100&url=/> >>> _______________________________________________ Secureideas-base-devel >>> mailing list Sec...@li... >>> <mailto:Sec...@li...> >>> https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel >>> >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> <http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> _______________________________________________ >> Secureideas-base-devel mailing list >> Sec...@li... >> <mailto:Sec...@li...> >> https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > Secureideas-base-devel mailing list > Sec...@li... > https://lists.sourceforge.net/lists/listinfo/secureideas-base-devel > |
From: GaRaGeD S. <ga...@gm...> - 2008-10-29 15:59:49
|
I wont go into refuting any idea, the facts are: - Base has come an go from GET to POST parameters at least a couple of times, none of the schemes is ideal. - Base on its stable line today is really lacking a lot of things that could make easier to implement new functionality, or even improve user experience - without templates and real javascript functionality (AJAX and the like) it will not go much further, we all know that for years now. - Implementing cache we could "correct" most of the back button problems, but that accounts for a lot of work I think base 2 is intended to overcome those issues, but is taking too long to make it's appearance even for developers. I think we need a little more leading here, if the designed team doesn't have enough time, ask for help please. Max -- $ echo "scale=1000000; 4*a(1)" | bc -l |
From: Kevin J. <ke...@in...> - 2008-10-29 16:57:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 29, 2008, at 11:59 AM, GaRaGeD Style wrote: > I wont go into refuting any idea, the facts are: > > - Base has come an go from GET to POST parameters at least a couple of > times, none of the schemes is ideal. > - Base on its stable line today is really lacking a lot of things that > could make easier to implement new functionality, or even improve user > experience > - without templates and real javascript functionality (AJAX and the > like) it will not go much further, we all know that for years now. > - Implementing cache we could "correct" most of the back button > problems, but that accounts for a lot of work Agreed. > I think base 2 is intended to overcome those issues, but is taking too > long to make it's appearance even for developers. I think we need a > little more leading here, if the designed team doesn't have enough > time, ask for help please. I agree that Second BASE has taken too long. I will repeat what has been sent out to the list many times, we are actively working on the project. We means the entire development list, anyone is welcome to join the conversation and start working on code. Max, I am just using your comment to say this, as I am aware that you have done work on the next version. Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkIlgoACgkQGDcWptZ2zmToHgCeJX3OfWMbTkrbdRv1/ISY8YN8 GFwAn2FGsozrStK9+E6KjWn3U6yrNWAW =ywDl -----END PGP SIGNATURE----- |
From: GaRaGeD S. <ga...@gm...> - 2008-10-29 17:58:55
|
I worked on two different approaches in the past. - I tried to implement "django" to the database but at least for me it was impossible to overcome the limited flexibility on database design that django accepts. Django has a lot of problems working with multiple keys on the same table, foreign keys are a little limited too. - I made a "functional mockup" of the main page with templates, using smarty, I don't even know if I still have that code, but it took me like 4 hours I think, to take out the HTML off the PHP file and implement it on templates, and I would take very little effort to implement cache too, smarty supports it. I would say that we should start throwing code to the base 2 tree, to attract the attention of all the interested developers. I think I could code a very basic functional system in a week, it would not be a lot, but using MVC with smarty, it would be trivial for any designer to create "themes", and it would be very simple to overcome most of the current defects using a javascript library (I like dojo) to make asynchronous calls, use nice widgets (tabs, sortable tables, very few or no complete refreshes), etc. There are some changes on adodb that could make our lives better too, I would love to simplify the string quoting procedure !! :) anyway, I wrote too much already, I will present some code someday in the next week. Max -- $ echo "scale=1000000; 4*a(1)" | bc -l |
From: Michael S. <ms...@ma...> - 2008-10-28 23:01:54
|
On Tue, Oct 28, 2008 at 04:40:08PM -0500, Micah Gersten wrote: >It's certainly more secure to store things in the session than in URLs. Bull. Secure from what? >Also, if you have trouble of sessions timing out during your lunch >break, just increase the timeout. No matter how long the timeout is, you'll eventually hit it. Unless you eliminate it, then you have a memory leak. >>> In what case would you want to use the back button? >> >> Any time I want to go back to the last page? Having a stupid "back" >> link is ridiculously less functional than the big honkin' "back" >> button or any of the other ways provided by the browser to go back. > >The back button is a carryover from the old days when everything was >static content. Nope, the back button is a fundamental UI item. Some overeager web designers think their nifty design is better, but that's a bug. Really good web apps make sure the back button works. Really good web design companies spend a lot of money on that, not because they're confused about whether they have static content, but because it's an important feature. >Also, depending on how stuff is stored in the session, >the back button could work just fine. The question comes back to, what >are you backing up to? Anytime I go from one screen to another, I expect the back button to take me back. That's why we call it the back button. >I find it very annoying when I see extremely long URLs in the location >bar. Well, it's your right to get annoyed about silly things. Maybe you should just turn off the location bar? (It's not like you can actually type in a URL in any useful fashion if your site depends on a bunch of hidden state to do anything useful.) Mike Stone |
From: Micah G. <mi...@on...> - 2008-10-28 22:13:57
|
Michael Stone wrote: > On Tue, Oct 28, 2008 at 04:40:08PM -0500, Micah Gersten wrote: >> It's certainly more secure to store things in the session than in URLs. > > Bull. Secure from what? More data in the URL means a higher chance of URL injection. It also means more data to sanitize. >> Also, if you have trouble of sessions timing out during your lunch >> break, just increase the timeout. > > No matter how long the timeout is, you'll eventually hit it. Unless > you eliminate it, then you have a memory leak. Yes, but generally, if you left your computer long enough for the timeout to occur, you've lost your train of thought anyways and need to start over. The problem is that it's more overhead in processing to have to reprocess all the GET parameters after every page load instead of using the session store that is loaded and you can either use the data or not. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com |