[PHP] Website beveiling, mogelijkheden

[Verwijderd]

Hoi,

Ik heb een vraag over de mogelijkheden van het beveiligen van een website. Is het mogelijk om met php ( of andere taal } te kijken of bijv de gebruiker ingelogd is op een domain, of dat je bijvoorbeeld de gebruikers naam kan achterhalen waarmee er is ingelogd op de pc??

De doel is om een intranet site online te zetten, maar een gewone wachtwoord beveiling vinden we te omslachtig, we willen eigenlijk als de gebruik de intranet site opend vanuit kantoor, dat die niet hoeft in te loggen. Ik heb al even zitten denken om het ip uitlezen van de gebruiker, en te kijken of die in een range voorkomt, maar een ip is niet uniek genoeg. Het mooiste zou zijn om te kijken of de gebruiker is ingelogd om een bepaald domain en zoniet dat je een login scherm krijgt.

Ik ben helaas onbekent met de mogelijkheden van php / java om dit op te lossen. Zou iemand mij misschien op weg kunnen helpen, waar ik moet zoeken, of eventuele voorbeelden?

Alvast bedankt.

[Tux]

Met een .NET webapplicatie is het zeker mogelijk om AD login gegevens te gebruiken. Met PHP of Java is het voor zover ik weet niet mogelijk.

[ Voor 14% gewijzigd door Tux op 09-01-2006 10:13 ]

[Verwijderd]

met .net ben ik wel bekend, en idd daar kan dat wel mee, maar een .net web applicaties is voor mij nog onbekend. Weet je toevallig een goede site waar ik daar wat meer over kan vinden?

[Mephix]

Je zou het ook kunnen laten afhandelen door je webserver.. LDAP voor apache of gewoon windows authentication voor IIS.

Hiermee kun je ook de gebruikersnamen afvangen met code (zal voor een .net app wel wat makkelijker gaan, maar kan met een php site ook).

[Verwijderd]

ok, klinkt erg intressant. Maar ik zit ff te denken, gaat dit wel werken omdat de website bij een provider staat.....


maar in iedergeval bedankt ga er zeker even meer over opzoeken. ( ben nu bezig om te kijken wat er mogelijk is via een vb webapplicaties. )

[Erkens]

Tux schreef op maandag 09 januari 2006 @ 10:12:
Met een .NET webapplicatie is het zeker mogelijk om AD login gegevens te gebruiken. Met PHP of Java is het voor zover ik weet niet mogelijk.

Vraag ik met toch af hoe .NET aan die login gegevens komt, die moet de browser dan verstrekken wat niet gedaan wordt.
overigens kan je met PHP en java hetzelfde bereiken als met .net, enige verschil is dat het in de ene taal wellicht iets lastiger is dan met de andere

[Verwijderd]

Ik weet niet hoe .net werkt met AD gegevens, maar het is ik ken wel de code om via .net de login gegevens van windows uit te lezen, niet de wachtwoord maar wel de gebruiker, die zou je dan vervolgens weer kunnen koppelen / laten zoeken in de gegevens van de AD.

Ik heb in tussen ook nog een andere optie gevonden, en dat is om via php ip's te blokkeren > een hele range en vervolgens ook om bepaalde addressen te allowen. Als ik een deny all erin zet en vervolgens een allow op het eterne ipadres van kantoor dan zou het toch meoten werken.

Maar ik hou om optie nog open, ideeën zijn nog welkom

[Bosmonster]

Verwijderd schreef op maandag 09 januari 2006 @ 10:36:
ok, klinkt erg intressant. Maar ik zit ff te denken, gaat dit wel werken omdat de website bij een provider staat.....

Als die bij een provider staat kun je het wel vergeten... Dan is het natuurlijk ook uberhaupt geen 'intranet' meer..

[vriesdude]

Met PHP kun je het AD domein en username ook opvragen, mits je via IIS 6.0 werkt op een Windows 2003 doos. Ik heb het zelfde gedaan voor het intranet op werk.

[Verwijderd]

hahaha, et is nog wel intranet hoor, alleen we hebben meerdere kantoren en een hoop bouw plaatsen en die mensen wil er ook de intranet kunnen zien. Technisch is de beste optie voor ons, dus vandaar dat de intranet online maar uiteraard beveilig komt.

En ja dat het niet mogelijk is, dat dacht ik al, maar bedankt voor het antwoord ( of ik dat niet meer uit te zoeken )

Met PHP kun je het AD domein en username ook opvragen, mits je via IIS 6.0 werkt op een Windows 2003 doos. Ik heb het zelfde gedaan voor het intranet op werk

zowel hier de test opstelling als me provider gebruiken allebei apache. Dus dat gaat dan helaas niet werken.

[ Voor 39% gewijzigd door Verwijderd op 09-01-2006 11:01 ]

[pjonk]

Erkens schreef op maandag 09 januari 2006 @ 10:40:
[...]
Vraag ik met toch af hoe .NET aan die login gegevens komt, die moet de browser dan verstrekken wat niet gedaan wordt.

Waarschijnlijk met NTLM authenticatie wordt ook alleen ondersteund door IE.

[vriesdude]

Verwijderd schreef op maandag 09 januari 2006 @ 10:58:

zowel hier de test opstelling als me provider gebruiken allebei apache. Dus dat gaat dan helaas niet werken.

hmm, .NET maakt gebruikt van de voorzieningen in IIS, ik denk niet dat het mogelijk is zonder IIS. Maar je zou het altijd kunnen proberen.. ik zal het Auth type eens opzoeken voor je...

[Bosmonster]

Verwijderd schreef op maandag 09 januari 2006 @ 10:58:
hahaha, et is nog wel intranet hoor, alleen we hebben meerdere kantoren en een hoop bouw plaatsen en die mensen wil er ook de intranet kunnen zien. Technisch is de beste optie voor ons, dus vandaar dat de intranet online maar uiteraard beveilig komt.

Dan noemen we zoiets dus een 'extranet'

[Verwijderd]

Lijkt me niet echt veilig wel? Een windows gebruikersnaam als controle?
Maar toch lastig, want laat je intern en extern een versie draaien of gaat alles extern.
Zo ja dan zou ik deze gewoon beveiligen met gebruikersnaam en wachtwoord icm een cookie die inlogtijd vastlegd ofzo.

Of je maakt een VPN netwerk en laat mensen op het bedrijf inloggen?
Weet alleen niet wat dat aan hardware gaat kosten.

[ Voor 19% gewijzigd door Verwijderd op 09-01-2006 11:08 ]

[vriesdude]

pjonk schreef op maandag 09 januari 2006 @ 10:58:
[...]

Waarschijnlijk met NTLM authenticatie wordt ook alleen ondersteund door IE.

code:

AUTH_TYPE  NTLM  
AUTH_USER  yyy\xxx

Werkt overigens ook in Firefox, via about:config iets aanpassen zodat de gegevens voorgegeven kunnen worden...

[Erkens]

vriesdude schreef op maandag 09 januari 2006 @ 11:08:
[...]

code:

AUTH_TYPE  NTLM  
AUTH_USER  yyy\xxx

Werkt overigens ook in Firefox, via about:config iets aanpassen zodat de gegevens voorgegeven kunnen worden...

wat al meteen aangeeft waarom je dat beter niet kan gebruiken voor authenticatie, immers iedereen kan deze gegevens mee sturen/veranderen

[Verwijderd]

Verwijderd schreef op maandag 09 januari 2006 @ 11:07:
Lijkt me niet echt veilig wel? Een windows gebruikersnaam als controle?
Maar toch lastig, want laat je intern en extern een versie draaien of gaat alles extern.
Zo ja dan zou ik deze gewoon beveiligen met gebruikersnaam en wachtwoord icm een cookie die inlogtijd vastlegd ofzo.

Of je maakt een VPN netwerk en laat mensen op het bedrijf inloggen?
Weet alleen niet wat dat aan hardware gaat kosten.

Wordt alleen een externe versie. VPN wordt nu ook gebruikt, maar er zijn bouwplaats waar er samengewerkt wordt met andere bedrijven waar weer geen vpn mogelijk, best lastig dus, dus vandaar we wel online moeten met die handel. Ook technisch is het voor ons makkelijk inverband met een project management systeem dat we gemaakt hebben.

Maar heb net even overlegt met me collega. We gaan nu eerst even kijken of het blokkeren van ip's voldoende, is wel een erg makkelijk optie maar we hebben nog geen nadelen kunnen bedenken.

In ieder geval alvast iedereen bedankt voor het mee denken. ( en de snelle reacties )

[Verwijderd]

is dat wel veilig? Er zijn mogelijkheden volgens mij om iemands mac adres terug te vragen door middel van php. Zocht net op google en er zijn classes voor geschreven. Koppen een ip aan een mac adres en je bent aardig safe dacht ik zo.

[ Voor 86% gewijzigd door Verwijderd op 09-01-2006 11:33 ]

[Verwijderd]

hmm, ok, maar dat houdt dan in dat ik dus van z'n 200 tot 250 pc's hun mac in moet voeren... of volstaat enkel de mac van de internet router dan??

[mschol]

vriesdude schreef op maandag 09 januari 2006 @ 10:56:
Met PHP kun je het AD domein en username ook opvragen, mits je via IIS 6.0 werkt op een Windows 2003 doos. Ik heb het zelfde gedaan voor het intranet op werk.

volgens mij had ik gezien dat je met apache zelfs zonder iis gebruik kan maken van AD authentificatie, d.m.v. het aanzetten in apache van ldap support..

[Guldan]

Ikzelf heb voor een project van school gebruik gemaakt van php om dit te realiseren. Ik gebruikte LDAP om het aanmelden te controleren. Zo kun je ook achterhalen in welke groep een user zit en alle verdere informatie die beschikbaar is in het domein. Als je dat nu combineert met een MAC adres dan zit je geloof ik vrij veilig.

Hier is een link voor je http://aspn.activestate.com/ASPN/Cookbook/PHP/Recipe/101525

Ook is hierover meer te vinden op www.php.net/ldap

[rrrandy]

Verwijderd schreef op maandag 09 januari 2006 @ 11:54:
hmm, ok, maar dat houdt dan in dat ik dus van z'n 200 tot 250 pc's hun mac in moet voeren... of volstaat enkel de mac van de internet router dan??

Je kunt ook een gebruiker om zijn wachtwoord vragen wanneer er van een onbekend MAC-adres wordt ingelogd. Dus: gebruiker logt voor de eerste keer in -> MAC onbekend -> vraag wachtwoord -> inloggen en MAC bewaren

Logt voor de tweede keer in: MAC bekend -> inloggen

Maar ja, of het veilig is is een tweede. Een gebruiker kan natuurlijk ook in zijn browser zelf aangeven dat het wachtwoord moet worden bewaard.

[ Voor 15% gewijzigd door rrrandy op 09-01-2006 14:03 ]

[Verwijderd]

tja, zo kom je telkens dingen tegen. Ik heb het zojuist getest. En het werkt prima ( Deny all ip's en allow alleen die ip's die toegang mogen )

Voor de genen die intresse hebben:

code:

<?

// Mode.  If you set this to 1 then you will BLOCK IPS in the blockip array.
// If set to 0, then you will be ALLOW ONLY IP's in the blockip array.

$bmode = 0;

// Note: if you are blocking a range (2.2.x) Make sure you put the
//       trailing . (period/dot) at the end or it may cause issues
//       with good ip ranges.
//

// $block ip is the IP of the person that you wish to block.
// You can add as many IP's as needed but keep the same format.
// The last IP will not need a ',' after it. The others will.
// 
// Example:
//
// $blockip = array("1.1.1.1",
//                  "2.2.2.2",
//                  "3.3."
//                 );

$blockip = array("1.2.3.4",
                     "1.2.3.4"
                     );



// $blockmsg is the message the user will see if they are blocked.
// 
// Example:
//
// $blockmsg = array("1.1.1.1 is not allowed.",
//                   "2.2.2.2 Blocked for forums abuse.",
//                   "3.3.3.3 We are temporarily down.",
//                  );


$blockmsg = ("you are not allowed to access this file")
                 
               

// Nothing to change below this line ------------------

$x = count($blockip);


for ($y = 0; $y < $x; $y++) {
  
  $brange = substr($REMOTE_ADDR, 0, strlen($blockip[$y]));

  if ($bmode == 1) {
    if ($_SERVER['REMOTE_ADDR'] == $blockip[$y] || ($brange == $blockip[$y])) {
      exit($blockmsg[$y]);    
    } else {
      $allow="Yes";
    }
  }
  
  if ($bmode == 0) {
    if ($_SERVER['REMOTE_ADDR'] == $blockip[$y] || ($brange == $blockip[$y])) {
      // return(1);
      $allow="Yes";   
    }
  }

}

if ($allow != "Yes") exit($blockmsg);

?>

en zet deze bovenaan de pagina waar het script op moet werken:

code:

<? include("blocker.php"); ?>

[LauPro]

Kan je IP-range restricties niet beter in een htaccess doen of op de vhost instellen?

[Schonhose]

Wat LauPro voorsteld is in dit geval wel handiger. Maar in het geval waarin je een aantal IP's wilt blacklisten en deze in een database hebt is de PHP oplossingen handiger.

[ Voor 8% gewijzigd door Schonhose op 09-01-2006 16:46 ]

[LauPro]

Mja, ik vraag me af of je überhaupt wel op deze manier je beveiliging moeten willen opbouwen. Kan je niet beter met certificaten werken, zowel server als client-side. Zodat je zonder certificaat er gewoon helemaal niet op komt. Je hebt het hier namelijk over een intranet (of extranet) met waarschijnlijk maximaal een paar honderd gebruikers. Lijkt me erg veel rompslomp c.q. overkill als je dan IP-ranges zou moeten kunnen blokkeren.

MAC adres opslaan/filteren is natuurlijk onzinnig. Aangezien dit alleen werkt als de client op dezelfde switch zit als de server (hetzelfde segment om het beter te zeggen). Wellicht dat je het kan gebruiken in een toepassing bij een WLan applicatie, maarja MAC-adressen heb je zo gespooft. Nog los van het feit dat je daarmee op computer koppelt ipv gebruiker (wat je min of meer af dwingt met zo'n certificaat). Certificaten kan je meenemen op een USB-stick of smartcard, er zijn verschillende implementaties van te vinden welke relatief eenvoudig in een web-based applicatie zijn te implementeren.

[Verwijderd]

Tja blokkeren hiermee zou inderdaad een rot werk zijn, maar zoals in ons geval zal ik rond de 15 max 20 ip adressen moeten toeveogen. Wat dus wel goed te doen is.

Het is ook niet 100% mijn favoriet, maarja om de gebruiker bij ieder bezoek in te laten loggen schiet ook niet op .

Maar die certificaten, kan iemand mij daar iets meer oververtellen?? Klinkt namelijk ook erg intressant.

Houdt dat in dat je een bestand op je pc moet hebben, en dat er dus gekeken wordt of je die hebt voordat je toegang krijgt??

[Verwijderd]

Hoe gaat dat in zijn werk met die certificaten? Daar ben ik ook wel benieuwd naar.

[LauPro]

Komt eigenlijk gewoon neer op SSL (dus minimaal een certificaat op de server), echter controlleer je op de server in je applicatie of de client die verbinding wil maken wel een geldig certificaat heeft. Dit zou je kunnen controlleren adhv public/private key.

[Verwijderd]

Maar dat houdt dus in dat als je website gehost worden bij een extern bedrijf ( bijv je provider ) dat het dus niet mogelijk is.

maar kan je zo soort gelijk iets niet zelf maken? Door simpel weg te zeggen dat je een bestandje om je pc moet hebben om de site te kunnen zien, Dus een php script dat kijkt of een bepaald bestand aanwezig is?? ( weet niet of php dat kan, maarja als je cookies kan opzoeken moet dat ook kunnen zo ik zeggen, of ben ik te voorbarig? )

[LauPro]

Waarom niet? Die client-certificaten moet je op de client installeren, op de server natuurlijk servercerticaten. Maar als je niets kan wijzigen aan de host waar het gehost wordt kan je natuurlijk nooit een optimale veilige omgeving garanderen lijkt me?

[Verwijderd]

klopt, zal je wat leuks vertellen, ik zal de naam van onze host niet noemen, maar even kort uitgelegt, ik heb een ftp functie nodig voor bepaalde scripts die hier gedraait worden en die dus vanzelf verbinding moeten maken met de ftp server van onze host en daar de bestanden neer te zetten, nu maak dat ftp progje heel leuk verbinding met de juiste map, maar daarna sprint die naar de root map van de server zelf, et is een linux bak, maar ik kan nu letterlijk alles van dat ding afhalen, alle users van dat bedrijf zelf, echt gewoon alles.

Dus tja idd krijg je het nooit 100% veilig, maar proberen kunnen we et wel.

[LauPro]

Als ik jou was zou ik dan naar je leidinggevende toestappen en de situatie uitleggen en een voorstel doen voor een veiliger alternatief (of als je dat zelf mag bepalen, waarom is dat nog niet gebeurd?). Ik weet niet met wat voor een reden je bij de huidige hoster zit. Maar als dit de situatie is zoals jij hem schetst dan zou ik zelf nooit de verantwoordelijkheid daarvoor willen dragen. Straks lever jij een (binnen jouw grenzen qua applicatie) een systeem op met een zeer hoog niveau en dan fietst klant Y binnen met een of andere trojan waardoor jullie gegevens op straat liggen. Blijkbaar werk je op een school of een overheidsinstelling (nfi) want ik kan me niet voorstellen dat een bedrijf zo laks met hun gegevens om zou willen gaan.

[Verwijderd]

Ik werk gewoon bij een bedrijf hoor, maar ik heb ze (onze host) vanochtend al gebeld en "op het matje geroepen". Laks omgaan met onze gegevens doen we niet, immers een buitenstaander komt er bij mij weten niet in, en ook voor die server van hun moet je nog steeds een login hebben.

Maar jij zegt een veiliger alternetief, hoe bedoel je dat percies? De beveiliging is gebasseerd op je externe ip die je door je provider krijgt. Die kan je dus niet veranderen. Je krijgt alleen toegang als je ip ( je internet ip adres dus ) overeenkomt met een lijst, die lijst kan je niet zomaar terug vinden.
Lijkt mij wel aardig dicht.

Dat van die server wordt ( hoop ik ) aangewerkt, maar met een gewone ftp programma zal niemand erachter komen. Waar ik inmiddels wel achter ben is dat je/ik niet in de mappen kan komen van de andere gebruikers / clients van hun. Ze heb dat gebied goed verborgen en je zal dus percies het pad en de map moeten weten om er te komen, bijkomend zijn die wel goed beveiligd en kom je dus niet in. DUs ben niet echt bang dat onze gegevens op straat komen te liggen.

[Hydra]

rrrandy schreef op maandag 09 januari 2006 @ 14:02:
Je kunt ook een gebruiker om zijn wachtwoord vragen wanneer er van een onbekend MAC-adres wordt ingelogd. Dus: gebruiker logt voor de eerste keer in -> MAC onbekend -> vraag wachtwoord -> inloggen en MAC bewaren

Een MAC adress opvragen van een remote machine die niet op hetzelfde segment zit gaat nooit lukken natuurlijk.

En ik snap niet dat er zo godsgruwelijk moeilijk wordt gedaan over een simpel probleem. Laat die mensen gewoon inloggen en geef ze de optie een cookie te zetten zodat ze dat maar eens per dag hoeven te doen, klaar.

[LauPro]

Verwijderd schreef op dinsdag 10 januari 2006 @ 13:29:
Maar jij zegt een veiliger alternetief, hoe bedoel je dat percies?

Heel simpel: weg bij die provider. Die mensen verstaan hun vak blijkbaar niet. Dus het lijkt me onverantwoord om daar een dergelijke applicatie op te gaan draaien waar blijkbaar goede beveiliging noodzakelijk is terwijl de beveiliging onder de maat is (als ik jou moet geloven).

Dat van die server wordt ( hoop ik ) aangewerkt

Blijkbaar heb je niet al te beste ervaringen met deze provider maar "hoop ik aan gewerkt" lijkt me nou niet echt een goede instelling. Ik kan niet helemaal achterhalen wat je nou precies kan doen. Maar het chrooten van (S)FTP-accounts lijkt me een van de basiszaken voor het beveiligen van een server.

Denk goed bij jezelf na: heb jij er op dit moment vertrouwen in dat de hostingzaken goed geregeld zijn. Kan jij 100% achter de oplossing staan zoals je die op wilt leveren naar de klant? Of er is hier geen budget waardoor dit soort situaties in de hand worden gespeeld óf men is blijkbaar vervallen in een soort tunnelvisie. Hoe dan ook lijkt me in elk geval iets om in acht te nemen. En mocht je de situatie zo laten zoals deze is, dan zou ik eigenlijk geen extra moeite doen om die applicatie nog meer te gaan beveiligen als de achterdeur wijd open staat.

[Verwijderd]

En ik snap niet dat er zo godsgruwelijk moeilijk wordt gedaan over een simpel probleem. Laat die mensen gewoon inloggen en geef ze de optie een cookie te zetten zodat ze dat maar eens per dag hoeven te doen, klaar.

Srry dat ik het misschien een beetje bot zeg, maar als je nou even op de vorig pagina kijkt, helemaal bovenaan, daar staat dus wrm we niet willen inloggen. ( Anders moet de gebruiker iedere keer inloggen als die op kantoor zit en dat willen we niet ) Kan omslachtig zijn, maar als dat de wensen zijn dan zal ik dat toch moeten proberen te maken.


@LauPro

Tja dit zijn gewoon lastige dingen, kijk de website staat bij onze internet provider ( ben ik geen voorstander van maar ok, er is al voor betaald ) Omdat hun een lek hebben noem ik maar ff geen naam, maar laat ik het zo zeggen, bel een helpdesk van een grote internet provider en je weet percies hoe slim ze zijn.

Einde van de dag was het nog niet opgelost, wat gewoon niet goed is ( zacht uitgedrukt ). Tevreden zijn we idd niet echt, en goede ervaring zijn er ook maar weinig, maar ga je als bedrijf zijn je internet ( waar je dus echt geen dag zonder kan ) verhuizen naar een andere provider, nee dat doe je niet zomaar.

Ik ben vanmiddag nog bezig geweest met dat ftp script, ben er toen ook achter gekomen hoe ik daar nou terecht kwam, heb het vervolgens met 4 andere " echte " ftp programma;s geprobeerd en dat ging niet, dus tja een combinatie van een bug en foutje bij hun geeft je toegang. Ben dus niet echt bang dat er morgen iemand anders achter kom. Bijkomend is het een nieuwe server , we zijn 1 van de eerste die daar gehost worden, omdat de andere servers geen php5 ondersteunen. We zijn dus niet echt bang dat onze gegevens op straat komen te liggen.

Maar wat wel zo is, is dat dit natuurlijk wel meegaat met de contract verlenging volgend jaar.

Ik kan niet helemaal achterhalen wat je nou precies kan doen

Zoals ik vanochtend ook tegen hun zei: Alles. Ik kan, op de mappen van de gebruikers na, alle bestanden kopieren, aanpassen, weggooien.

wat wel " komische" ( eerder stom ) was, was de reactie van de helpdesk medewerken, ik vertelde hem dat ik alles op hun server kon doen ect. Kreeg ik als reactie : en dit wilt u melden?

[wizzkizz]

kun je niet gewoon een dedicated server bij die externe partij huren? of evt. co-location voor je eigen server? of voor alleen dit extranet een andere hosting-partij in de arm nemen?

Als het bedrijf waar je werkt ongeveer 250 werkplekken (en dus wss minimaal zoveel werknemers) heeft en het de security een beetje serieus neemt, is het bedrag van een paar honderd euro toch peanuts?

[Voutloos]

Verwijderd schreef op dinsdag 10 januari 2006 @ 22:52:
Ik ben vanmiddag nog bezig geweest met dat ftp script, ben er toen ook achter gekomen hoe ik daar nou terecht kwam, heb het vervolgens met 4 andere " echte " ftp programma;s geprobeerd en dat ging niet, dus tja een combinatie van een bug en foutje bij hun geeft je toegang. Ben dus niet echt bang dat er morgen iemand anders achter kom. Bijkomend is het een nieuwe server , we zijn 1 van de eerste die daar gehost worden, omdat de andere servers geen php5 ondersteunen. We zijn dus niet echt bang dat onze gegevens op straat komen te liggen.

Welk programma jij gebruikt staat hier los van. Een FTP server bij shared hosting hoort altijd users binnen hun eigen mapje te houden.

Dit moet gewoon gemeld worden en serieus aangepakt worden. Als ze het niet op zeer korte termijn kunnen aanpassen, mag je je imo wél bang zijn dat je gegevens op straat liggen.

Maar wat wel zo is, is dat dit natuurlijk wel meegaat met de contract verlenging volgend jaar.

Als ze dit niet binnen korte termijn (binnen 2 werkdagen imo) fixen, ben je gek als je uberhaupt ooit nog zaken met ze wil doen.

[Hydra]

Verwijderd schreef op dinsdag 10 januari 2006 @ 22:52:
Srry dat ik het misschien een beetje bot zeg, maar als je nou even op de vorig pagina kijkt, helemaal bovenaan, daar staat dus wrm we niet willen inloggen. ( Anders moet de gebruiker iedere keer inloggen als die op kantoor zit en dat willen we niet ) Kan omslachtig zijn, maar als dat de wensen zijn dan zal ik dat toch moeten proberen te maken.

Software engineering = ook de gebruiker aanraden die wensen bij te stellen als dat een betere applicatie oplevert. Domweg maar doen wat zij zeggen is niet per definitie te beste keus, helemaal als iets dergelijks een kleine moeite is. 1 keer dag/week/whatever inloggen, big deal. je zit je nu in onmogelijke bochten te wringen om iets heel simpels.

[LauPro]

Verwijderd schreef op dinsdag 10 januari 2006 @ 22:52:
[...]
maar ga je als bedrijf zijn je internet ( waar je dus echt geen dag zonder kan ) verhuizen naar een andere provider, nee dat doe je niet zomaar.

Inmiddels heb ik enkele tientalle bedrijven meegeholpen met een verhuizing van hun oude hosting partner naar het bedrijf waar ik werk. En dat varieerd dan van een organisatie met 100 medewerkers tot kleine met een paar mensen in dienst. In geen geval grote problemen gehad, natuurlijk is het voor mij best veel werk, maar als je het goed doet heb je als klant zijnde erg weinig te doen, en wanneer alles in een weekend gebeurd dan is de overlast ook miniem. Dus vraag eens wat offertes aan zo her en der, wellicht dat er een partij is die de zaken veel beter voor jullie kan regelen. (Wat jou misschien eindelijk weer tijd bespaard, aangezien het heen-en-weer gebel jou ook tijd kost nu.)

Maar wat wel zo is, is dat dit natuurlijk wel meegaat met de contract verlenging volgend jaar.

Als je aantoonbaar kan maken dat de huidige beveiliging onder de maat is en ze reageren/ondernemen actie niet binnen de tijd van de SLA dan kan je dat contract zo ontbinden.

ik vertelde hem dat ik alles op hun server kon doen ect. Kreeg ik als reactie : en dit wilt u melden?

Direct doorvragen naar tweedelijns, niet blijven hangen bij die eerstelijns .