Toon posts:

Application "includen" welke buiten je docroot staat

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0Henk 'm!

  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Ik ben de hele dag al aan het brainstormen en zoeken hoe ik het beste PHP applicaties welke je standalone kunt gebruiken kunt "includen" in je eigen script. De reden waarom ik dit wil is omdat de "geinclude" applicatie dan op zichzelf blijft staan en makkelijker te upgraden is. Ik wil tevens voorkomen door middel van het buiten de doc_root plaatsen van een dergelijke applicatie dat deze op zichzelf wordt aangeroepen.

Nu is het nogal trivial om een applicatie te includen met include() door gewoon een pagina te laden en hier de include in te zetten. Een tweede probleem waar je tegenaan loopt is dat je documentroot voor de applicatie niet meer klopt met van waar je het daadwerkelijk aanroept. Veel applicaties hebben geen doc_root setting in hun config staan dus wordt het allemaal een beetje dirty.

Ik heb ook al de mogelijkheid bekeken om een Apache Alias aan te maken en deze dan alleen vanaf localhost benaderbaar te maken door middel van een .htaccess zodat de URL niet vanaf externe IP's benaderd kan worden.
edit:
in dit geval zou ik overigens gebruik maken van een iframe waar ik denk ik sowieso niet onderuit komt


Zelf vind ik het allemaal erg dirty en probeer een manier te vinden om dergelijke programma's als een soortement van module te laden. Het lijkt mij dat het laden van een module op zich mogelijk moet zijn, ook zonder het volledig aanpassen van een dergelijke applicatie.

Applicaties waar ik aan denk als voorbeeld zijn:

- Webmail
- Gallery
- Chat
- etc.

Er zijn voldoende PHP varianten van te vinden, vaak alleen geen idee hoe je dit zou kunnen "includen" in je eigen script browsel.

Moet ik gaan kijken naar een manier hoe ik modules kan laden in mijn script of zijn er ook andere manieren welke netjes te verwerken zijn ?

[Voor 3% gewijzigd door RutgerM op 12-06-2011 20:22]

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


Acties:
  • 0Henk 'm!

  • 8088
  • Registratie: December 2000
  • Niet online

8088

NaN

Het probleem is me niet volledig duidelijk, maar zijn symlinks geen optie om de doc_root-horde te overbruggen? Je zou ook API's voor je applicaties kunnen schrijven, maar dat is wel een hoop extra werk.

Do you seek to engage in or have you ever engaged in terrorist activities, espionage, sabotage, or genocide?


Acties:
  • 0Henk 'm!

  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Ik zal het probleem proberen te verduidelijken.

Ik heb een intranet met de url:

www.intranet.tld/

Een gebruiker kan hier op inloggen en zijn ding doen.

Omdat ik het makkelijk vindt om hier door andere personen geschreven applicaties IN te gebruiken zal ik deze moeten laden in mijn intranet.

Normaal zal je zonder manier van includen krijgen: www.intranet.tld/applicatie

Dit zal de applicatie ook nodig hebben omdat het beschibaar moet zijn via je browser.

Nu wil ik dat natuurlijk ook bereiken maar dan niet onder directory van de applicatie zelf maar in mijn intranet php script tool ding. Om tegen te gaan dat de applicatie op zichzelf geladen zal worden kan ik dus geen /home/www.intranet.tld/applicatie gebruiken maar zal ik deze in /home moeten zetten in een /home/applications folder en de applicatie daar dus uit moeten laden in mijn intranet... which is impossible krijg ik het gevoel.

Een API zou mogelijk zijn maar inderdaad onnoemelijk veel werk.


Echter is op deze manier

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


Acties:
  • 0Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 19:27

Janoz

Moderator Devschuur®

!litemod

Ik begrijp niet helemaal welk probleem je denkt op te moeten lossen. Als je het al in een eigen pagina zou willen zetten dan kan dat enkel middels een iframe of het aanpassen van de applicatie (denk alleen al aan de html start tag). Als je een iframe zou gebruiken dan moet de app per definitie van buiten beschikbaar zijn.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0Henk 'm!

  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Janoz schreef op zondag 12 juni 2011 @ 21:08:
Ik begrijp niet helemaal welk probleem je denkt op te moeten lossen. Als je het al in een eigen pagina zou willen zetten dan kan dat enkel middels een iframe of het aanpassen van de applicatie (denk alleen al aan de html start tag).
Klopt helemaal, dat zou een optie kunnen zijn.
Als je een iframe zou gebruiken dan moet de app per definitie van buiten beschikbaar zijn.
En dat wil ik dus niet, de app van buiten beschikbaar. En dat zou dus een dubbele uitdaging worden vrees ik.

Het moet opzich mogelijk zijn. Drupal en dergelijke frameworks doen dit ook, dus waarom zou je het zelf niet kunnen maken. Drupal als voorbeeld is wellicht weer lastig omdat dit zijn eigen manier van modules laden heeft.

[Voor 15% gewijzigd door RutgerM op 12-06-2011 22:58]

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


Acties:
  • 0Henk 'm!

  • Freeaqingme
  • Registratie: April 2006
  • Laatst online: 21:37
Drupal en dergelijke frameworks doen dit ook, dus waarom zou je het zelf niet kunnen maken
Omdat Drupal modules specifiek voor Drupal geschreven worden. Je kan ook niet zomaar een drupal module in een typo3 applicatie zetten. Als je dan zo nodig een application framework wil gebruiken zou je beter eens naar Drupal of Symfony kunnen kijken.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


Acties:
  • 0Henk 'm!

  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Freeaqingme schreef op zondag 12 juni 2011 @ 23:41:
[...]


Omdat Drupal modules specifiek voor Drupal geschreven worden. Je kan ook niet zomaar een drupal module in een typo3 applicatie zetten. Als je dan zo nodig een application framework wil gebruiken zou je beter eens naar Drupal of Symfony kunnen kijken.
Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.

Het nadeel van dergelijke frameworks vind ik dat je weer op een andere manier moet gaan programmeren, dus dat zal ik niet doen. Maar dat is een andere discussie welke we hier niet moeten voeren, hier heb ik al voldoende research voor gedaan. Ik heb mijn eigen framework dat letterlijk MVC doet.

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


  • Kwastie
  • Registratie: April 2005
  • Laatst online: 26-05 11:50

Kwastie

Awesomeness

RutgerM schreef op zondag 12 juni 2011 @ 23:55:
[...]
Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.
Het laden is triviaal.

"Ze" hebben deze "problemen" opgelost door een API te maken, en omdat iedere module zich aan deze API houdt integreert het meestal goed.

Simpel gezegd kun je het bijvoorbeeld op deze manier oplossen: (ik neem hierbij wel aan dat je een een "single point of entry" hebt)

Ergens definieer je welke "modules" beschikbaar zijn , vervolgens geef je per module aan hoe de URL er uit ziet. (bijv. "Gallery" -> site.nl/foto/). Iedere module weet zelf wat er moet "gebeuren".

Stel, de gebruiker opent "site.nl/foto/view/1". Je applicatie laad de module "Gallery", en die module weet dat hij bij "/view/1" een foto moet weergeven.

Zo werkt trouwens https://www.djangoproject.com/ ook

[Voor 3% gewijzigd door Kwastie op 13-06-2011 00:47]

When I get sad i stop being sad and be awesome instead


  • Freeaqingme
  • Registratie: April 2006
  • Laatst online: 21:37
RutgerM schreef op zondag 12 juni 2011 @ 23:55:
[...]


Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.

Het nadeel van dergelijke frameworks vind ik dat je weer op een andere manier moet gaan programmeren, dus dat zal ik niet doen.
Als je moet kiezen tussen het wiel volledig opnieuw uitvinden, of een reeds bestaande oplossing gebruiken en enkel wat nieuwe dingen moeten leren zal je normaal gesproken /altijd/ op de 2e oplossing uitkomen. Als programmeur moet je toch ook de api van de programmeertaal waar je op dat moment in programmeert leren? En die van 3rdparty api's, en de shortcuts van je IDE, en ....

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Freeaqingme schreef op maandag 13 juni 2011 @ 01:50:
[...]


Als je moet kiezen tussen het wiel volledig opnieuw uitvinden, of een reeds bestaande oplossing gebruiken en enkel wat nieuwe dingen moeten leren zal je normaal gesproken /altijd/ op de 2e oplossing uitkomen. Als programmeur moet je toch ook de api van de programmeertaal waar je op dat moment in programmeert leren? En die van 3rdparty api's, en de shortcuts van je IDE, en ....
Ik snap wat het bedoelt alleen vraag ik me sterk af of je via API's zaken wilt gaan aansturen.

Ik heb bijvoorbeeld Gallery2 bekeken en daar de API van geraadpleegd. Waarom zou je alles via de API doen ? wijzigen ze iets in de API zal je zaken aan moeten passen, dit blijft toch maar dan nog. Het "inladen" van een volledige tool zou makkelijker zijn voor de implementatie natuurlijk :)

Ik wil geen quick en dirty maar probeer te bekijken hoe andere developers dit doen welke dergelijke tools implementeren. Ik zie daar overigens weinig API gebruik.

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


  • Freeaqingme
  • Registratie: April 2006
  • Laatst online: 21:37
Ik heb het niet enkel over externe webservices. Bij een programmeertaal vormen de beschikbare functies en hun parameters een api. Bij een framework vormen de beschikbare classes, methodes, en hun parameters een api.

Een kenmerk van goede api's is dat je als je een versie gebruikt, die versie in principe nooit zal veranderen.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • RutgerM
  • Registratie: Juli 2005
  • Laatst online: 09-12-2018

RutgerM

exec(rm -rf /*);

Topicstarter
Ik heb het momenteel alleen even over een webservice, excuus voor de onduidelijkheid.

Wat je zegt klopt, opzich zal een API nooit mogen veranderen, ik heb echter andere ervaringen. Vandaar dat ik een op zichzelf staande app wil "includen" zodat hij eigenlijk op zichzelf draait, wellicht met wat login tweaks, maar wel in een schil.

Liever een Kakker in een Asobak dan een Stakker in een Patserbak :D


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
RutgerM schreef op maandag 13 juni 2011 @ 12:08:
Wat je zegt klopt, opzich zal een API nooit mogen veranderen, ik heb echter andere ervaringen. Vandaar dat ik een op zichzelf staande app wil "includen" zodat hij eigenlijk op zichzelf draait, wellicht met wat login tweaks, maar wel in een schil.
Helaas, er is geen silver bullet hier, dus een beter antwoord dan dat van Freeaqingme gaat er voor jou niet uitrollen. :)

En omdat er geen heilige graal is, doet iedereen het anders, of vanuit de andere kant gezien: anders had iedereen niet zo moeilijk gedaan. ;) Je hebt gewoon een conventie/API/hoe-je-het-ook-noemt nodig, en daarbij krijg je inderdaad vanzelf de verantwoordelijkheid erbij om dat stabiel te houden en niet bij elke release helemaal om te gooien.

Een van de moeilijkste aspecten bij het bedenken van een API is dat het echt helemaal doorgedacht moet zijn, zodat je het voldoende backwards (en forwards) compatible kan houden, zonder dat je binnen no-time permanent in een hoekje zit te huilen vanwege alle legacy of slechte design keuzes. :P Of je zelf iets maakt of een bestaand systeem adopteert maakt mij niet uit (jouw topics kennende wil je het toch zelf opnieuw uitvinden), maar speel tenminste wel serieus met wat bestaande implementaties, zodat je gewoon leert wat wel en niet mooi werkt.

[Voor 25% gewijzigd door Voutloos op 13-06-2011 12:59]

{signature}

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee