Admin dashboard, best practices

[DimitryK]

Hi allemaal,

Als we kijken naar simpele websites die bijvoorbeeld met Wordpress gebouwd zijn, dan zien we heel vaak de /wp-admin url. Zelfde geldt natuurlijk voor andere cms oplossingen met bijv. /backend, /admin, /<random url>.

Momenteel ben ik zelf een platform aan het bouwen en ook hier moet natuurlijk een admin dashboard achter komen. Echter zit ik te twijfelen over de aanpak hiervan. Ik heb al een en ander opgezocht, maar natuurlijk heeft iedereen hier zijn/haar eigen mening over.

Mijn ideeën.
Ik kan het dashboard op een subdomain zetten, zoals backend/admin/dashboard.domain.xyz. Ik kan een simpele url structuur aanhouden zoals /admin, /backend, /dashboard, etc. Of ik kan doen wat sommige CMS'en doen, security through obscurity en een random backend url genereren (en vervolgens je url niet meer kunnen herinneren...).

Als ik kijk naar grotere platforms, zoals bijvoorbeeld Tweakers, Facebook e.d. dan valt daar nergens iets te bespeuren van een dashboard. Geen subdomains, geen url structuren (bekend voor de buitenwereld althans), noem het maar op.

Hoe doen zij zoiets? Gaat dit via een API en een desktop tool, of werken zij ook met een doodnormaal dashboard?

Bvd.

[RedHat]

dsp.tweakers.net

Voor de rest gewoon je admin panel goed beveiligen en neerzetten waar jij dat handig vind.

[mbarie]

Al zet je een login-link op elke pagina, waar je admin panel staat maakt in mijn ogen niet veel uit, als het maar gedegen is gebouwd. Er zijn een paar dingen die het al snel relatief veilig maken. Gebruik van PDO en parameterized queries voorkomt SQL injectie, en een eventueel throttling mechanisme voorkomt overmatige hoeveelheden aan login-pogingen. HTTPS maakt het moeilijker om iemand zijn login-verzoek af te luisteren en het wachtwoord te stelen.

DimitryK schreef op zondag 20 december 2015 @ 08:30:
Hoe doen zij zoiets? Gaat dit via een API en een desktop tool, of werken zij ook met een doodnormaal dashboard?

Dit verschilt per implementatie en benaderingswijze. Het hangt af van de budgetten/tijd en wensen/eisen die jij en je klanten hebben. In welke mate je herbruikbaarheid nastreeft. Alle 3 de implementaties (ik verzin een web-based dashboard die praat tegen een API endpoint er even bij) hebben zo hun voor- en nadelen. Als je hier dieper op in wil gaan zal je ook iets meer moeten vertellen over welke keuze je wil maken, en waarom.

[ Voor 25% gewijzigd door mbarie op 20-12-2015 10:28 ]

[DimitryK]

RedHat schreef op zondag 20 december 2015 @ 10:00:
dsp.tweakers.net

Voor de rest gewoon je admin panel goed beveiligen en neerzetten waar jij dat handig vind.

Weet iets geleerd over Tweakers

mbarie schreef op zondag 20 december 2015 @ 10:21:
Al zet je een login-link op elke pagina, waar je admin panel staat maakt in mijn ogen niet veel uit, als het maar gedegen is gebouwd. Er zijn een paar dingen die het al snel relatief veilig maken. Gebruik van PDO en parameterized queries voorkomt SQL injectie, en een eventueel throttling mechanisme voorkomt overmatige hoeveelheden aan login-pogingen. HTTPS maakt het moeilijker om iemand zijn login-verzoek af te luisteren en het wachtwoord te stelen.


[...]


Dit verschilt per implementatie en benaderingswijze. Het hangt af van de budgetten/tijd en wensen/eisen die jij en je klanten hebben. In welke mate je herbruikbaarheid nastreeft. Alle 3 de implementaties (ik verzin een web-based dashboard die praat tegen een API endpoint er even bij) hebben zo hun voor- en nadelen. Als je hier dieper op in wil gaan zal je ook iets meer moeten vertellen over welke keuze je wil maken, en waarom.

Platform wordt gebouwd in Laravel, dus PDO is standaard. Ook login throttling, wordt gebruikt, alsook access control en HTTPS is standaard voor alle pagina's.

Ik zat zelf te denken aan een subdomein, gezien dat het makkelijkste is in mijn optiek. Makkelijk te onthouden en qua adres/url-structuur gescheiden van de publieke pagina's. Enige twijfel hierbij was dat iedereen het zo kan vinden in je DNS records...

[Ramon]

Het maakt echt niets uit waar je je beheeromgeving neerzet. Ik ben ook niet bekend met enige best practices hierover. Zoals hierboven gezegd is het vooral belangrijk dat het veilig is.

domein.nl/admin/ is mijns-inziens net zo makkelijk te onthouden als admin.domein.nl, misschien is de eerste optie qua usability nog wel makkelijker omdat 'admin/' makkelijk erachter te typen is als je al op de site bent.

Misschien kan je je klanten vragen wat zij gewend zijn?

[ Voor 26% gewijzigd door Ramon op 20-12-2015 11:07 ]

[SPee]

Dat subdomein is te prefereren, omdat dat geen beperking legt op de url die je klant kan gebruiken.
Hij kan dan dus een eigen /admin url aanmaken.

[Gomez12]

SPee schreef op zondag 20 december 2015 @ 11:54:
Dat subdomein is te prefereren, omdat dat geen beperking legt op de url die je klant kan gebruiken.
Hij kan dan dus een eigen /admin url aanmaken.

Hangt er vanaf wat je doelgroep is, als het puur iets voor jezelf is dan kan je een subdomein aanpak kiezen, is het voornamelijk gericht op grote bedrijven dan kan je ook een subdomein kiezen, maar moet het voor iedereen zijn dan moet je je afvragen of iedereen wel een subdomein kan aanmaken (hint dat kunnen mensen vaak genoeg niet)

[CH4OS]

Het is ook afhankelijk hoe simpel je de web app wilt hebben voor andere gebruikers. Als de admin in een subdomein moet, is dat lastiger te configureren voor gebruikers met shared webhosting. True; zij kunnen ook subdomeinen aanmaken, maar is toch lastiger dan een submapje.

[ Voor 10% gewijzigd door CH4OS op 22-12-2015 22:00 ]

[johnkeates]

Er is niet zo zeer een 'best practice' voor waar je je admin panel neerzet. Het valt eigenlijk meer onder algemene beveiliging. Voor derden is het niet 'moeilijker' om je aan te vallen als je geen standaard /admin URL gebruikt, op z'n best ontkom je dan aan de standaard vuln scanners, maar die zou je al in de serverconfiguratie moeten afvangen.

Wat je qua security qua admin omgeving eigenlijk qua verandering (heel veel qua! ) kan doen om wat minder vatbaar voor aanvallen te zijn is gewoon geen public admin ingang hebben. Stop alles achter een VPN of binnen een bedrijf LAN-only.

[CH4OS]

Tja, het mooiste is natuurlijk als je de admin inderdaad zou kunnen beveiligen, door bijvoorbeeld een bepaald IP-adres of -range kan includen voor de admin. Maar dat is wel sterk afhankelijk van de aard van de web app.

[Oerdond3r]

Ik denk dat je admin-panel verstoppen valt onder het 'security by obscurity' principe. Een principe dat over het algemeen niet toegejuicht wordt. Je kan het wel gebruiken, maar je moet het niet als een essentieel onderdeel van je beveiliging maken.

Als je perse vanaf het publieke web je administratiedingen wilt regelen ( en wie wil dat nou niet? ) moet je er gewoon voor zorgen dat je applicatie aan de huidige beveiligingsnormen voldoet.

( Stiekem heb ik ook nog een phpMyAdmin draaien op een ander pad dan de standaard )