Ik heb nogal wat tools en beveiliging lopen op IP
$SERVER vars overhoop door provider
- Infopolitie
- Berichten: 38
- Lid geworden op: 30 okt 2017, 10:48
$SERVER vars overhoop door provider
Iemand enig idee wat je ermee moet als je provider $SERVER['REMOTE_ADDRESS'] gaat vullen met 1 van zijn 2 ipv6 caching servers en de client ip mee gaat sturen in $_SERVER["HTTP_X_CLIENTIP"] anders dan hardcoded de core files aanpassen?
Ik heb nogal wat tools en beveiliging lopen op IP
Ik heb nogal wat tools en beveiliging lopen op IP
Re: $SERVER vars overhoop door provider
Is dit een algemene vraag of echt gerelateerd aan phpBB?
- Infopolitie
- Berichten: 38
- Lid geworden op: 30 okt 2017, 10:48
Re: $SERVER vars overhoop door provider
Ik zit met een groot phpbb board met dit probleem Ger... Ik zie de update naar 3.2.1 en lees dat we "toch nooit core files hoeven te wijzigen dus we kunnen heel gemakkelijk gewoon de update doen door alle 3.2.0 bestanden weg te knikkeren en een clean 3.2.1 install erneer te kwakken en die te gebruiken". Dus ja, echt phpbb, dit is toch een phpbb forum?
Dit is gewoon 1 van mijn hele kleine probleempjes waar ik nu tegenaan loop, ik ben nieuw hier dus ik dacht, ik gooi het eens in de groep...
Re: $SERVER vars overhoop door provider
Dat is prima, maar ik zie nog steeds niet waar in phpBB je dit nodig zou hebben?Infopolitie schreef: ↑31 okt 2017, 18:16Ik zit met een groot phpbb board met dit probleem Ger... Ik zie de update naar 3.2.1 en lees dat we "toch nooit core files hoeven te wijzigen dus we kunnen heel gemakkelijk gewoon de update doen door alle 3.2.0 bestanden weg te knikkeren en een clean 3.2.1 install erneer te kwakken en die te gebruiken". Dus ja, echt phpbb, dit is toch een phpbb forum?![]()
Dit is gewoon 1 van mijn hele kleine probleempjes waar ik nu tegenaan loop, ik ben nieuw hier dus ik dacht, ik gooi het eens in de groep...![]()
Kun je iets meer specifiek aangeven waar je tegenaan loopt? We willen je met plezier helpen, maar dan moeten we wel snappen wat er aan de hand is.
- Infopolitie
- Berichten: 38
- Lid geworden op: 30 okt 2017, 10:48
Re: $SERVER vars overhoop door provider
Dag Ger,
Dank je wel voor je input,
Ik liep er tegenaan en had het snel opgelost, zoals gezegd hardcoded de genoemde $SERVER variabele aanpassen nadat onze provider besloot dat het een briljant idee was om REMOTE_ADDRESS te gaan gebruiken en standaard te vullen met een van zijn caching server ip-adressen. Zoals je wellicht weet is autorisatie en authenticatie 3-ledig: ip, pass en username... als 1 van die 3 altijd bij iedereen identiek is... heb je een probleempje en als dat bij een hele grote NL provider is kan ik me niet voorstellen dat ik de enige in NL ben die daar last van heeft.
Ik heb een groter probleemje want extra tools op IP, dus ik had er nog meer last van, wellicht dat ik het extra snel bemerkte.
Gelukkig heeft niemand ervan gehoord dus misschien heeft enkel mijn cluster bij die provider er last van.
Dank je wel voor je input,
Ik liep er tegenaan en had het snel opgelost, zoals gezegd hardcoded de genoemde $SERVER variabele aanpassen nadat onze provider besloot dat het een briljant idee was om REMOTE_ADDRESS te gaan gebruiken en standaard te vullen met een van zijn caching server ip-adressen. Zoals je wellicht weet is autorisatie en authenticatie 3-ledig: ip, pass en username... als 1 van die 3 altijd bij iedereen identiek is... heb je een probleempje en als dat bij een hele grote NL provider is kan ik me niet voorstellen dat ik de enige in NL ben die daar last van heeft.
Ik heb een groter probleemje want extra tools op IP, dus ik had er nog meer last van, wellicht dat ik het extra snel bemerkte.
Gelukkig heeft niemand ervan gehoord dus misschien heeft enkel mijn cluster bij die provider er last van.
Re: $SERVER vars overhoop door provider
Heb je het nu over de Sessie IP validatie (ACP -> Algemeen -> Beveiligingsinstellingen)? En dan nogmaals: waar loop je precies tegenaan?
- Infopolitie
- Berichten: 38
- Lid geworden op: 30 okt 2017, 10:48
Re: $SERVER vars overhoop door provider
Nee joh, 't is al opgelost. 