[BF4] Stats webpage for XpKiller's Stats Logger Plugin

[ImportBot]

Originally Posted by ty_ger07*:

 

The link in the first post is the github link which will always point to the most current version.

https://github.com/tyger07/BF4-Serve...zipball/master

[ImportBot]

Originally Posted by EntraVenuS*:

 

so do i just overwrite all files and fill the config.php in with the database details ?

[ImportBot]

Originally Posted by ty_ger07*:

 

correct

[ImportBot]

Originally Posted by ty_ger07*:

 

It seems like you are now mixing old files with new files. Good luck on your quest. I will not support that sort of activity. It's just way too much work for me to try to help you with all the things you keep on modifying.

[ImportBot]

Originally Posted by EntraVenuS*:

 

ok as it is not working (still) i will delete all files and upload the link you gave me in the other post

[ImportBot]

Originally Posted by ty_ger07*:

 

Your stylesheet is still a bit out of date, missing some elements, and a bit broken.

For example, .banoutline, .warnoutline, and .bansubscript are missing from your stylesheet. Also, the #topcontent, #topmenu, and #menucontent scrolling is broken due to your outdated stylesheet.

[ImportBot]

Originally Posted by Rebellx*:

 

Hope I'm in the right forum

 

Has the problem that the signature is not displayed, what can be the reason?

 

Banners Fehler ? Server ID ?

 

https://freiezocker-clan.de/bf4stats...p=server&sid=1

 

 

showthread....-0-0-2/page166*

 

In which folder do I have to change what?

[ImportBot]

Originally Posted by Rebellx*:

 

Signature is not displayed ?

 

https://freiezocker-clan.de/bf4stats...ure.png_pid=63

[ImportBot]

Originally Posted by ty_ger07*:

 

Refering to the following forum post ( myrcon.net/...chat-guid-stats-and-mapstats-logger#entry46457 ) which was posted in the wrong thread, below is the conversation and my reply.

 

Has the problem that the signature is not displayed, what can be the reason?

 

Banners Fehler ? Server ID ?

 

https://freiezocker-clan.de/bfserver...p=server&sid=1

In which folder do I have to change this?

As time is available, I will work on providing an update to the code in order to provide a acceptable solution to anyone who is experiencing the same issue.

 

I believe the solution will require adding the query to the extension rewrite in the .htaccess files in both the ./common/server-banner/ and ./common/signature/ folders. As it is now, your webserver, for whatever reason, is cutting off the query string from the URL when it rewrites the .png reference to the correct .php extension. I don't know what set of conditions causes your webserver to do that when other webservers I have tested do not. But, I plan to implement a universal solution as time is available. I will let you know here once the update is released.

[ImportBot]

Originally Posted by Rebellx*:

 

Okay thanks

[ImportBot]

Originally Posted by ty_ger07*:

 

Okay thanks

The ./common/server-banner/.htaccess and ./common/signature/.htaccess files have been updated in the most recent code revision.

 

Please give it a try and please let me know the results.

 

These are direct links to the newest versions of the two files:

 

https://github.com/tyger07/BF4-Serve...nner/.htaccess

 

https://github.com/tyger07/BF4-Serve...ture/.htaccess

 

 

As always, this is a direct link to the newest version of the entire stats webpage code:

 

https://github.com/tyger07/BF4-Serve...zipball/master

[ImportBot]

Originally Posted by Rebellx*:

 

Good Morning,

Both files are replaced by common / server-banner / .htaccess

And the common / signature / .htaccess

 

Procon restarted but no change

 

https://freiezocker-clan.de/bf4stats...p=server&sid=1

[ImportBot]

Originally Posted by ty_ger07*:

 

I will seek advice from the hive mind. By default, the web server uri rewrite is supposed to include the query string. I don't know why your server isn't behaving like default and I apparently am using the wrong approach to correct it.

[ImportBot]

Originally Posted by Rebellx*:

 

I also do not know, okay I'm waiting for solution and thanks for your help

[ImportBot]

Originally Posted by ty_ger07*:

 

I asked over on stackoverflow. I will see if anyone smarter than me has some good ideas.

http://stackoverflow.com/questions/4...n-htaccess-uri

[ImportBot]

Originally Posted by Rebellx*:

 

That would be super, everything must run around

[ImportBot]

Originally Posted by ty_ger07*:

 

Well, I don't know.

 

https://forums.evga.com/FindPost/2649835

Since it's a single user and you're not able to replicate the issue on your installations/troubleshooting I would tend to think that their Apache server is misconfigured in some way. Either their .htaccess is too restrictive for remote rewrites or something else. I'll take a look at your project and see what, if anything, I can see that may be an issue. From the looks of things, especially when I head on over to your links provided above, all appears to be correct. I'll see if I can replicate the person's issue, if possible, and if so see if I can help remediate.

...

 

https://forums.evga.com/FindPost/2649952

It's always good to get a second set of eyes on anything. Especially when you're looking into regex conditionals in Apache. They can be very cryptic and confusing a lot of the time.

 

I haven't been able to recreate the issue on my CentOS 6/7 servers using apache 2.x at all. The rewrite rule with variable passing works just fine when I pass it to a test machine. I think the user who was having an issue may have misconfigured their system and it's not processing it appropriately. Perhaps they may need to show what modules they have activated and/or any other customized configurations they have going which may cause it to ignore the variable being passed.

[ImportBot]

Originally Posted by leibhold*:

 

Are you sure there is no other rewrites on the server?

 

Just a thought if some one beefed up security in a strange way.

 

Think more access to the server configuration may provide the answer.

Acts like there is a rewrite to remove the QUERY_STRING from the URL

 

If the QUERY_STRING has any value at all besides blank than the_at the end of .php? tells mod_rewrite to remove the QUERY_STRING from .php and redirect.

 

RewriteEngine On

RewriteBase /

RewriteCond %{QUERY_STRING} .

RewriteRule ^.php .php? [L]

 

Just an idle thought.

[ImportBot]

Originally Posted by Rebellx*:

 

But the tested is not synonymous

 

RewriteEngine On

RewriteBase /

RewriteCond% {QUERY_STRING}.

RewriteRule ^ .php .php? [L]

[ImportBot]

Originally Posted by leibhold*:

 

The example rewrite is example of possible problem with Apache server configuration. Not meant to be used.

 

The rewrite used by this system works but not on your Apache

 

So the problem is with your configuration.

 

Turn on rewrite logging for short time while testing.

 

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#

 

See what is happening.

[ImportBot]

Originally Posted by Rebellx*:

 

With Apache server configuration. I do not know myself but I could tell my provider what to do. I just need to know exactly what to do

[ImportBot]

Originally Posted by leibhold*:

 

You will have to tell your provider what is happening and ask them to look at it.

 

Your Apache setup with your provider is not something we can diagnose here via posts.

 

The system works on a lot of servers

 

It doesn't work on your server

[ImportBot]

Originally Posted by Rebellx*:

 

Reply from the supplier

 

Dear Mr Andreas,

Thank you for your message.

 

There is no error in Apache Server. This is used by thousands of hosting customers without any problems.

 

In Forum post it was pointed out to mod_rewrite. This also is available on your webspace.

 

However in the forum it was shown on outdated Apache / mod_rewrite version (2.2):

 

Http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#

 

This we do not use. On our servers we are using current Apache 2.4 version. There it will be used the following mod_rewrite documentation:

 

Http://httpd.apache.org/docs/current...d_rewrite.html

 

If your script uses old Apache 1.3 rewrite commands this does not work with current Apache 2.4 version. Under 2.4 it is necessary to use current rewrite commands.

 

By Forum Post I assume that your script is outdated in this point. Ask vendors of script for current Apache 2.4 rewrite usage.

[ImportBot]

Originally Posted by ty_ger07*:

 

I really wish they could explain what is "outdated" about the following .htaccess code. Like, specifically, what? Because I don't see any "old" rewrite commands below. All of the below "old" commands are listed as perfectly valid in the "new" 2.4 documentation.

 

Code:

RewriteEngine on
RewriteRule ^(.*)\.png $1.php [NC,L]

Your web server is rewriting the URI as expected; so it is working. The part that isn't working is that your web server is chopping the query string off the end. Can they explain?

 

 

 

http://httpd.apache.org/docs/current...ml#rewriterule

By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.

So, please ask them why their server is not behaving as it says it is supposed to "by default".

 

 

 

Is it because I am not including this stuff?

Code:

DocumentRoot "/var/www/example.com"
<Directory "/common/server-banner">
</Directory>

I sure hope not. My hope is that per-directory .htaccess files do not require that information and can understand their location and scope without problem. I cannot include that missing information because it is impossible for me to guess users' web server directory structures to determine the DocumentRoot and it is impossible for me to guess which sub-directory a user may place my webpage code.

 

The "old" and "new" Apache documentation has the same requirements in this regard and it works perfectly fine on the "old" servers; so it should work perfectly fine on the "new" servers as well. In fact, it IS working perfectly fine on your web server (it is rewriting the file name as expected); it is just that your web server is chopping off the query string for some reason (which is incorrect behavior according to the Apache documentation).

 

 

 

Additionally, the server on which I tested used Apache version 2.4.23; so it was "new" Apache and worked without issue. Please have them explain what exactly they believe I am doing wrong and why. As far as I -- and a small group of others -- can tell, it is your web server which is behaving incorrectly.

 

Thank you!

[ImportBot]

Originally Posted by Rebellx*:

 

Dear Mr Andreas,

 

Thank you for your message.

 

The QueryString is passed through unchanged from Rewrite / Apache to PHP. A test carried out justified this. This is an Apache default setting that has not been modified by us and therefore can not be the cause of the problem.

 

If the script only requires this one rewrite rule, this is also excluded as a cause.

 

The DocumentRoot is also set correctly in the web server.

[ImportBot]

Originally Posted by ty_ger07*:

 

Ok, so they say that there is no problem and everything is working fine. They imply that there is nothing wrong with my .htaccess code either. The only problem is that their web server is not passing on the query string the way it is supposed to and they have no idea why. They claim that it is passing on the query string the way it is supposed to; but clearly it is not.

 

Can you please ask them to see for themselves that it is not passing on the query string properly when performing a .htaccess mod_rewrite?

 

 

This works (not matching the mod_rewrite rule):

https://freiezocker-clan.de/bf4stats/common/signature/signature.php_pid=63

https://freiezocker-clan.de/bf4stats...ure.php_pid=63

 

 

This does not work (matching the mod_rewrite rule):

https://freiezocker-clan.de/bf4stats/common/signature/signature.png_pid=63

https://freiezocker-clan.de/bf4stats...ure.png_pid=63

 

 

Given the information they have available and after seeing the above in action for themselves, they have no idea why?

[ImportBot]

Originally Posted by leibhold*:

 

ty_ger07 - got more patience then me.

 

It works EVERY WHERE except your apache server = there is an issue with your apache server.

[ImportBot]

Originally Posted by Rebellx*:

 

Dear Mr Andreas,

 

Thank you for your message.

 

The cause is not the rewrite, but the file ending you use. An image file can not get any GET variables passed. You simulate with your rewrite that it is a picture.

If you use exactly the same rewrite, but with the extension .html, you will see that the parameters are passed cleanly by the rewrite. I have inserted the same rewrite again, but with the .html extension:

 

Https://freiezocker-clan.de/bf4stats...re.html_pid=63

 

RewriteRule ^ (. *) \. Html signature.php_% {QUERY_STRING} [NC, L]

 

Your method does not work with an image file transfer, you must use a change which supports the variables (PHP, CGI, HTML ...).

 

I hope I could help you.

If you have any further questions, please do not hesitate to contact us.

 

Best regards

[ImportBot]

Originally Posted by Rebellx*:

 

Info from webhoster

Dear Mr Andreas,

 

Thank you for your message.

 

On the server nothing can be changed. Supported image files do not get any parameters. There must be your developer to change this. For example, it could work with filenames like signature-63.png and then extract the rewrite from it. This is the most common method for image files.

I hope I could help you.

If you have any further questions, please do not hesitate to contact us.

 

Best regards

 

 

- Technical 2. Level Engineer -

[ImportBot]

Originally Posted by ty_ger07*:

 

Hmm. Interesting. It's interesting that other web servers allow "images" to have a query string. I do agree that it is odd for an image to have a query string, but it's also odd that your web server doesn't allow it when other web servers do allow it. The only reason I used the PNG extension instead of its actual PHP extension is because some forum BBcode won't allow it to be inserted as an image unless certain extensions are used.

 

Ok, so a small rewrite is needed.

 

Thank you for providing me with this information. I will need to make and test the change.