/dev/null
- Overig
zijn de incompetente flash developers van adobe naar magento verplaatst of heb ik het fout?
13-02-2021, 14:45 door Anoniem, 6 reacties
Vraag van iemand was:
"Is it possible to use wget instead of php in cron for Magento 2?"
Antwoord van adobe is:
"I think the answer to the question is straightforward - no, you cannot use wget instead of php in cron in Magento 2. And we are not likely to add this by default due to security ramifications."
Mijn vraag is nu ben je het eens met dit antwoord, en waarom wel of niet? Denk er eerst over na voordat je mijn argumentatie hieronder leest.
https://community.magento.com/t5/Just-Ask-Alan/Is-it-possible-to-use-wget-instead-of-php-in-cron-for-Magento-2/m-p/25418/highlight/true#M155
Als je niets van hosting of shared hosting configuraties weet, en puur logisch zou redeneren. Dan zou je volgens mij moeten concluderen dat het gebruik van wget/curl impliceert een executie onder en in een omgeving die speciaal geconfigureerd is voor de web applicatie en exact hetzelfde is aan deze web applicatie.
Het uitvoeren van een cron job, wat dus een andere omgeving is als de web applicatie, heeft dus per definitie andere eigenschappen. Als je er dan van uitgaat dat de webapplicatie omgeving specifiek geconfigureerd is voor webapplicaties, is de kans groot dat elke andere omgeving hier minder aan voldoet. Met deze aanname ligt het dus in de lijn der verwachting dat elke andere omgeving minder geschikt is, en dus ook minder veilig.
Voorbeeld is de openbase dir van php. Hiermee kan je forceren dat php scripts alleen een bepaald deel van de user home kunnen benaderen. Ook kan je forceren dat een script slechts 30 seconden mag runnen.
Als je php executeerd via de command line, zijn dit soort restricties niet meer van toepassing.
Dus wat mij betreft, zijn ze bij adobe aan het prutsen en/of mensen opzettelijk aan het misleiden.
"Is it possible to use wget instead of php in cron for Magento 2?"
Antwoord van adobe is:
"I think the answer to the question is straightforward - no, you cannot use wget instead of php in cron in Magento 2. And we are not likely to add this by default due to security ramifications."
Mijn vraag is nu ben je het eens met dit antwoord, en waarom wel of niet? Denk er eerst over na voordat je mijn argumentatie hieronder leest.
https://community.magento.com/t5/Just-Ask-Alan/Is-it-possible-to-use-wget-instead-of-php-in-cron-for-Magento-2/m-p/25418/highlight/true#M155
Als je niets van hosting of shared hosting configuraties weet, en puur logisch zou redeneren. Dan zou je volgens mij moeten concluderen dat het gebruik van wget/curl impliceert een executie onder en in een omgeving die speciaal geconfigureerd is voor de web applicatie en exact hetzelfde is aan deze web applicatie.
Het uitvoeren van een cron job, wat dus een andere omgeving is als de web applicatie, heeft dus per definitie andere eigenschappen. Als je er dan van uitgaat dat de webapplicatie omgeving specifiek geconfigureerd is voor webapplicaties, is de kans groot dat elke andere omgeving hier minder aan voldoet. Met deze aanname ligt het dus in de lijn der verwachting dat elke andere omgeving minder geschikt is, en dus ook minder veilig.
Voorbeeld is de openbase dir van php. Hiermee kan je forceren dat php scripts alleen een bepaald deel van de user home kunnen benaderen. Ook kan je forceren dat een script slechts 30 seconden mag runnen.
Als je php executeerd via de command line, zijn dit soort restricties niet meer van toepassing.
Dus wat mij betreft, zijn ze bij adobe aan het prutsen en/of mensen opzettelijk aan het misleiden.
Reacties (6)
13-02-2021, 17:03 door
[Account Verwijderd]
Door Anoniem: Vraag van iemand was:
"Is it possible to use wget instead of php in cron for Magento 2?"
Antwoord van adobe is:
"I think the answer to the question is straightforward - no, you cannot use wget instead of php in cron in Magento 2. And we are not likely to add this by default due to security ramifications."
Mijn vraag is nu ben je het eens met dit antwoord, en waarom wel of niet? Denk er eerst over na voordat je mijn argumentatie hieronder leest.
https://community.magento.com/t5/Just-Ask-Alan/Is-it-possible-to-use-wget-instead-of-php-in-cron-for-Magento-2/m-p/25418/highlight/true#M155
Als je niets van hosting of shared hosting configuraties weet, en puur logisch zou redeneren. Dan zou je volgens mij moeten concluderen dat het gebruik van wget/curl impliceert een executie onder en in een omgeving die speciaal geconfigureerd is voor de web applicatie en exact hetzelfde is aan deze web applicatie.
Het uitvoeren van een cron job, wat dus een andere omgeving is als de web applicatie, heeft dus per definitie andere eigenschappen. Als je er dan van uitgaat dat de webapplicatie omgeving specifiek geconfigureerd is voor webapplicaties, is de kans groot dat elke andere omgeving hier minder aan voldoet. Met deze aanname ligt het dus in de lijn der verwachting dat elke andere omgeving minder geschikt is, en dus ook minder veilig.
Voorbeeld is de openbase dir van php. Hiermee kan je forceren dat php scripts alleen een bepaald deel van de user home kunnen benaderen. Ook kan je forceren dat een script slechts 30 seconden mag runnen.
Als je php executeerd via de command line, zijn dit soort restricties niet meer van toepassing.
Dus wat mij betreft, zijn ze bij adobe aan het prutsen en/of mensen opzettelijk aan het misleiden.
"Is it possible to use wget instead of php in cron for Magento 2?"
Antwoord van adobe is:
"I think the answer to the question is straightforward - no, you cannot use wget instead of php in cron in Magento 2. And we are not likely to add this by default due to security ramifications."
Mijn vraag is nu ben je het eens met dit antwoord, en waarom wel of niet? Denk er eerst over na voordat je mijn argumentatie hieronder leest.
https://community.magento.com/t5/Just-Ask-Alan/Is-it-possible-to-use-wget-instead-of-php-in-cron-for-Magento-2/m-p/25418/highlight/true#M155
Als je niets van hosting of shared hosting configuraties weet, en puur logisch zou redeneren. Dan zou je volgens mij moeten concluderen dat het gebruik van wget/curl impliceert een executie onder en in een omgeving die speciaal geconfigureerd is voor de web applicatie en exact hetzelfde is aan deze web applicatie.
Het uitvoeren van een cron job, wat dus een andere omgeving is als de web applicatie, heeft dus per definitie andere eigenschappen. Als je er dan van uitgaat dat de webapplicatie omgeving specifiek geconfigureerd is voor webapplicaties, is de kans groot dat elke andere omgeving hier minder aan voldoet. Met deze aanname ligt het dus in de lijn der verwachting dat elke andere omgeving minder geschikt is, en dus ook minder veilig.
Voorbeeld is de openbase dir van php. Hiermee kan je forceren dat php scripts alleen een bepaald deel van de user home kunnen benaderen. Ook kan je forceren dat een script slechts 30 seconden mag runnen.
Als je php executeerd via de command line, zijn dit soort restricties niet meer van toepassing.
Dus wat mij betreft, zijn ze bij adobe aan het prutsen en/of mensen opzettelijk aan het misleiden.
Misschien zijn zij aan het prutsen, misschien niet. maar alsjeblieft.... láát toch in vredesnaam buiten beschouwing dat er opzettelijke misleiding wordt geëxploiteerd/gegenereerd!
Er is mondiaal al véél te véél ruis en onrust dat alleen maar leidt tot nog meer segregatie op willekeurig welk (sociaal) niveau, discipline of vakgebied..... spekkie naar het bekkie voor (aspirant) Conspiricy Theorists.
13-02-2021, 18:12 door
Anoniem
Er is mondiaal al véél te véél ruis en onrust dat alleen maar leidt tot nog meer segregatie op willekeurig welk (sociaal) niveau, discipline of vakgebied..... spekkie naar het bekkie voor (aspirant) Conspiricy Theorists.
Opzettelijk misleiden als in van: We zeggen maar dat dit secure is, zodat we niet extra programmeer werk hebben. Je weet wel hetzelfde advies als je internet provider helpdesk belt en ze laten je router restarten of nog erger router laten resetten.
13-02-2021, 19:03 door
Anoniem
De aspirant futurist met het antwoord van dertien jaar geleden:
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
14-02-2021, 01:10 door
Anoniem
Door Anoniem: De aspirant futurist met het antwoord van dertien jaar geleden:
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
Houdt het gescheiden? Hoe bedoel je dit precies?
wget en exec maken allebei gebruik van socket.h
So what is the difference?
21-02-2021, 02:11 door
Anoniem
Door Anoniem: De aspirant futurist met het antwoord van dertien jaar geleden:
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
https://raamdev.com/2007/using-wget-to-run-a-php-script/
wget is een linux commando en exec een PHP commando.
Bartok plays punk houdt het liever spannend. Neen, Magento 2 gaat wget niet fasciliteren.
Houdt het gescheiden - html - PHP etc.
Of gaan we "roerbakken"? Makan, makan.
Joris Goedbloed
Wow he, jij begrijpt de essentie totaal niet. Het gaat niet om hoe de pagina wordt aangeroepen en vanaf waar. Hier is als voorbeeld wget/curl.
21-02-2021, 02:23 door
Anoniem
Pfff, ok ok bedankt voor de reacties. Ik begin nu het algemeen niveau te begrijpen, wat ongetwijfeld bij Adobe hetzelfde is. Wat vaak beter werkt is:
- eerst goed lezen
- dan oordelen of je inderdaad genoeg weet van het onderwerp (iets van >10 jaar er mee werken)
- zo ja, dan kan je een inhoudelijke reactie geven.
- eerst goed lezen
- dan oordelen of je inderdaad genoeg weet van het onderwerp (iets van >10 jaar er mee werken)
- zo ja, dan kan je een inhoudelijke reactie geven.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Security Architect
Samenwerken aan de veilige verduurzaming van Nederland. Jij bent de security architect die er graag voor zorgt dat oplossingen in de IT en/of OT veilig zijn. De impact die jij samen met jouw collega’s hebt op de digitalisering binnen Alliander is groot. Kunnen wij op jou rekenen?
Medior OT Security Specialist
Samen werken aan een stabiel energie-netwerk en daarmee een mooie bijdrage leveren aan de maatschappij. Daar haal jij veel energie uit als Medior OT Security Specialist! Met jouw expertise draag jij graag bij aan de veilige verduurzaming van Nederland.
