FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » FUDforum Development » Bug Reports » Unable to set avatars in user CP
Show: Today's Messages :: Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
Unable to set avatars in user CP [message #20070] Fri, 24 September 2004 04:42 Go to next message
jmccombs is currently offline  jmccombs   United States
Messages: 8
Registered: September 2004
Location: Northern Virginia
Karma: 0
Junior Member
Any time I try and use one of the Avatars I've uploaded into the system via the User CP, I immediately get punted to the registration page with errors for ALL the required information sections (username being too short, pasword being too short, no valid email address).

Using the CP to update my other information (name, gender, preferences, etc) works fine however.

Any ideas?

I'm wondering if this is something specific to my installation. I ran the XMB conversion script to a 2.5.0 release, then updated 2.5.0 to 2.6.6...





Do pyromaniacs wear blazers?
Re: Unable to set avatars in user CP [message #20083 is a reply to message #20070] Fri, 24 September 2004 14:31 Go to previous messageGo to next message
Ilia is currently offline  Ilia   Canada
Messages: 13241
Registered: January 2002
Karma: 0
Senior Member
Administrator
Core Developer
Hmm is the PHP install on your system allow for file uploads?
If you are uncertain, create a simple test.php script with
<?php
phpinfo
();
?>
and look at the value of the file_uploads option (should be ON or 1).

Also, let me know what version of PHP are you using.


FUDforum Core Developer
Re: Unable to set avatars in user CP [message #20084 is a reply to message #20070] Fri, 24 September 2004 14:45 Go to previous messageGo to next message
jmccombs is currently offline  jmccombs   United States
Messages: 8
Registered: September 2004
Location: Northern Virginia
Karma: 0
Junior Member
php version 4.3.8

file uploads are on.

Actually I need to correct myself too. The avatar collections were copied into the fudforum directory under images/avatars straight from the XMB install. I used the admin utilities to scan the directory and load them that way.

I ran all the DB utilities scripts to verify it wasn't an issue there (consistency, compact, optmize, reindex, - not nessacarily in that order) and everything came up clean. (well the search index thing always seems to time out)

-Jeff


Do pyromaniacs wear blazers?

[Updated on: Fri, 24 September 2004 14:45]

Report message to a moderator

Re: Unable to set avatars in user CP [message #20087 is a reply to message #20084] Fri, 24 September 2004 16:07 Go to previous messageGo to next message
Ilia is currently offline  Ilia   Canada
Messages: 13241
Registered: January 2002
Karma: 0
Senior Member
Administrator
Core Developer
Send me a private message with the admin login information to the forum and I will review the situation.

FUDforum Core Developer
Re: Unable to set avatars in user CP [message #20089 is a reply to message #20070] Fri, 24 September 2004 16:59 Go to previous messageGo to next message
jmccombs is currently offline  jmccombs   United States
Messages: 8
Registered: September 2004
Location: Northern Virginia
Karma: 0
Junior Member
You have PM. Smile

I wonder.. We're using two web servers for this;

1. standard Apache 1.3.31/mod_ssl - servers non-dynamic content (static HTML, images, etc) on serverA
2. an 'application' Apache 1.3.31, which serves PHP, Perl and java on serverB.

We us a combination of mod_rewrite and mod_proxy to get content back to the app server. e.g.

<Location /forum>
  RewriteEngine On
  RewriteRule /forum/(.*) http://10.0.3.147:80/forum/$1 [P]
</Location>


is found in our web servers httpd.conf file. I've run into problems with this kind of a setup before, where apps such as XMB, Cerberus, and others try and auto-detect the hostname when they set cookies or do session security checking. Usually, I have to hack up the source a bit when this is done. Create a findhostname() function and replace all the $SERVER_NAME variables with the output from findhostname(); and for session security, I usually have to reference $SERVER['http_x_forwarded_for'] or whatever that variable is instead of trusting the requester variable.

I didn't think I'd need to do this, since Fud's install process asked me to set the cookie domain....


Do pyromaniacs wear blazers?

[Updated on: Fri, 24 September 2004 17:01]

Report message to a moderator

Re: Unable to set avatars in user CP [message #20105 is a reply to message #20089] Sun, 26 September 2004 19:42 Go to previous messageGo to next message
Ilia is currently offline  Ilia   Canada
Messages: 13241
Registered: January 2002
Karma: 0
Senior Member
Administrator
Core Developer
Do you have 2 physical webservers who are sharing data via HFS or equivalent or is it simply 1 physical server with 2 webserver apps running on it on different ports. The problem could be that the "image" server is missing the image file...

I tried to login to the forum using the info in PM, but got an error (details in PM).


FUDforum Core Developer
Re: Unable to set avatars in user CP [message #20112 is a reply to message #20070] Mon, 27 September 2004 01:19 Go to previous message
jmccombs is currently offline  jmccombs   United States
Messages: 8
Registered: September 2004
Location: Northern Virginia
Karma: 0
Junior Member
The forums system, since the images are 'dynamic' enough (avatar uploads, etc) is run entirely from the 'application' server.

The static content "web" server is used just for static web and images. The reason we do this, is twofold;

1. Plain old web servers aren't loading a ton of application modules (e.g. mod_perl, php, java connectors such as mod_caucho (for resin) or mod_jk for tomcat). Since the majority of the content we serve from our portal systems is static, we can fit more regular web servers on a single system since base-apache instances have a smaller memory foot-print than ones with all those modules loaded. Our base platform for a web server is a Sun V100, with 512MB and a single CPU, and that 1 box can serve a ton of pages. App servers are usually bigger boxes with more memory. Keeps our infrastructure costs manageable.

2. masking applications behind proxy servers located on private networks (that are firewalled to heck and back) decreases the security risks associated with poor code... we do the same for the databases too actually. The *only* thing allowed to talk on the application server network is web traffic. The *only* services those application servers have is apache. Only one system from a seperate 'management' tier is allowed to ssh into them, everything else is disallowed. We actually do the same for our postgres, mysql, and Oracle database servers. -- it's restrictive, true, and it makes administration a major pain, but it decreases the risk associated with problems because some dumb developer isn't escaping URIs properly, or there's a expoit in mod_perl/mod_php. -- Don't get me wrong, this isn't foolproof, but it does make life just a teensy bit harder for all the black hats out there - except for those that are determined to get in of course. Sad

-- as for the way they are laid out.. they're actually entirely seperate systems. While they do mount a NFS file system (across yet another seperate network) since in reality we have 3 each of web/app servers (everything is load balanced) the document root, server instances, even logs are in seperate directories. The two systems don't touch in any way.

You should be able to access the system now, sorry about that. Details in PM. I appreciate all your help on this, as I'm throughly stumped.

-j


Do pyromaniacs wear blazers?

[Updated on: Mon, 27 September 2004 01:26]

Report message to a moderator

  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: "mark all messages read" - redirection
Next Topic: SQL Error if search contains special characters
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Mon Nov 25 03:54:49 GMT 2024

Total time taken to generate the page: 0.02274 seconds