|
Post by votan on Sept 21, 2008 16:09:17 GMT -5
Seems like there is a problem with the UserAddress$ variable. No matter what I do, from where I connect (LAN or WAN), the UserAddress$ always returns 127.0.0.1. I espically put my server on the net to test this even when connecting from non-internal networks... and it still always returns 127.0.0.1. So there is definitely somethng not working right.
|
|
|
Post by Carl Gundel - admin on Sept 21, 2008 18:23:35 GMT -5
Are you running behind Apache?
-Carl
|
|
|
Post by votan on Sept 21, 2008 18:28:58 GMT -5
yes......
|
|
|
Post by Carl Gundel - admin on Sept 21, 2008 19:03:56 GMT -5
That's why you're seeing that address. Your web browser is asking Apache for something. Then Apache is forwarding the request to Run BASIC, so RB sees the address of the Apache server.
There is probably some way to tell Apache to forward the originating address, but I haven't figured it out.
-Carl
|
|
|
Post by votan on Sept 22, 2008 7:23:57 GMT -5
|
|
|
Post by votan on Sept 29, 2008 9:27:18 GMT -5
Hmmm... this seems to be a tricky thing that is not really easy to solve with RB. In order to retreive the clients IP when running RB behind apache, RB needs to be able to access the header information... Here is some short article about how to solve it (with using apache as a reverse proxy and php)Maybe that's something that could be added to RB sometimes? ;D Full article here: devcentral.f5.com/weblogs/macvittie/archive/2008/06/02/3323.aspx
|
|
|
Post by carlgundel on Sept 29, 2008 10:02:08 GMT -5
Hmmm... this seems to be a tricky thing that is not really easy to solve with RB. In order to retreive the clients IP when running RB behind apache, RB needs to be able to access the header information... Here is some short article about how to solve it (with using apache as a reverse proxy and php)Maybe that's something that could be added to RB sometimes? ;D Full article here: devcentral.f5.com/weblogs/macvittie/archive/2008/06/02/3323.aspxI'm sorry. What exactly do you think should be added to Run BASIC? If Apache is forwarding the request to Run BASIC with localhost as the address then Run BASIC can't just guess the originating IP address out of thin air. -Carl
|
|
|
Post by carlgundel on Sept 29, 2008 12:59:11 GMT -5
I'm sorry. What exactly do you think should be added to Run BASIC? If Apache is forwarding the request to Run BASIC with localhost as the address then Run BASIC can't just guess the originating IP address out of thin air. Okay, now that I've actually read the article I can see what you're getting at. I'm open to doing something like this, but let's see what else we can learn before I add Apache-specific features to RB. Thanks for the feedback. -Carl
|
|
|
Post by votan on Dec 18, 2008 13:01:33 GMT -5
Ok, I was digging a bit more into the "forward client IP to server when running RB behind a reverse proxy"-issue. I needs a way to read the Header information that gets send by the overlaying proxy. Like for Apache and most other proxies, adding the X-FORWARDED-FOR directive to the logging line will include the client IP in the header that the proxy then will forward to RB. Without this feature, it will never be possible to use any IP related features of RB when rinning behind another server. Here are some more resources about the X-FORWARDED-FOR directive... maybe it helps in figuring out a solution!? en.wikipedia.org/wiki/X-Forwarded-Fordevcentral.f5.com/weblogs/macvittie/archive/2008/06/02/3323.aspxI really need to run RB behind apache... for being able to use .htaccess, bandwidth throtteling, IP limits, country mapping etc... So would be more than uber cool if you can address this issue. And as other languages like php, java etc can read the header-information by just using one command, it should be possible to achieve this with RB, too.
|
|
|
Post by votan on Dec 22, 2008 21:44:35 GMT -5
Well, seems like such a feature will not come so soon!? So... how else could I solve this issue??? I was thinking about maybe running two instances of RB. One RB instance running on port 80 for the public part and the other instance behind the apache reverse proxy on a different port, serving the secured area. Guess I will use custom DNS settings for the second instance, to avoid adding the port number to the url all the time.. still have to use something like "http://protected.somewebsite.com" though..... Guess transfering data from one instance to another could only be done by putting additional info into the url or by using html submit. But I somehow have the feeling that this will make me stumble upon unforseeable issues!? Any ideas if this could work? This could at least enable me to use some of the advanced apache features with RB... even though any IP processing by RB will still be impossible.... Would be cool if I could convice you, Carl, to add a "read http header" feature as this would finally enable me to add advanced security features and more controll to my projects. Else I will have to try to work with two instances, what would only be a lame workaround....
BTW.... any news about fixing the "highjackable sessions"-problem and the "/seaside/go/" stuff in the url and other seaside leftovers in the html code?
|
|
|
Post by Carl Gundel - admin on Dec 22, 2008 22:03:22 GMT -5
Well, seems like such a feature will not come so soon!? I admit it hasn't been on the top of my list. That sounds interesting and it may not be too hard to do either. These things are possible, but not in the short run. -Carl
|
|
|
Post by votan on Dec 22, 2008 22:13:58 GMT -5
Guess the biggist problem about this is... it makes every site, no matter how well designed, look super amateurish.... ..... and "not in the short run" sounds VERY far away..
|
|
|
Post by Carl Gundel - admin on Dec 23, 2008 10:34:14 GMT -5
Guess the biggist problem about this is... it makes every site, no matter how well designed, look super amateurish.... What does? This? or this? The hi-jackable session issue could me a concern for some, but the Seaside stuff in the URL is essentially cosmetic, and most users aren't going to care about it. I'll try to have something for people to try in the next couple of months but it'll be a test release. -Carl
|
|
|
Post by votan on Jan 14, 2009 4:14:10 GMT -5
Could it be the pro version that you are talking about? BTW..... don't want to bother you again... but just saw that the "/seaside/go/" stuff in the url and other seaside leftovers in the html code made my sites drop to the bottom in the google rankings.... so it's not just cosmetical anymore. Have to switch back to my old sites meanwhile to get the traffic back up. Can you tell us already more about the "test release" you were talking about? Will it support mysql? Will it be the interpreter only, without the build in webserver? Another thing I was thinking about could be usefull for something like a "pro version" would be the ability to encrypt code.... so that programmers could prevent others from viewing/altering code.... would be important in cases where you want to protect code like if you want to sell programs or lock programs to a given domain or so....
|
|
|
Post by Carl Gundel - admin on Jan 14, 2009 8:22:13 GMT -5
Could it be the pro version that you are talking about? BTW..... don't want to bother you again... but just saw that the "/seaside/go/" stuff in the url and other seaside leftovers in the html code made my sites drop to the bottom in the google rankings.... so it's not just cosmetical anymore. Have to switch back to my old sites meanwhile to get the traffic back up. It isn't likely that any of that stuff has affected your Google rankings. The Run BASIC site itself it built on Seaside and it ranks quite well for terms like easy web programming and learn web programming. The content of your pages and the links pointing to your site are most important. The test release will have bug fixes and maybe a few new features. The "Pro" version is a ways off yet. MySQL and other popular databases will be supported. We don't have any plans for a non-web version of Run BASIC at this time. People cannot view the code for your programs. The Run BASIC webserver will only serve up content in the public folder, not in the projects folder. -Carl
|
|