IOS / Android "wrapper"-app

[Bas112]

Beste Tweakers,

Heeft er iemand ervaring met goed gekeurde applicaties (wrapper: browser openen - responsive pagina inladen) ?

Ik lees ontzettend veel tegenstrijdige berichten, ik hoop dus dat hier iemand recent een applicatie met succes in de store / market heeft geplaatst.

Korte schets van de applicatie:

1. check of het device verbonden is met internet, zo niet foutmelding.
2. Als er wel verbinding is: twee textfields (gebruikersnaam, wachtwoord) en een button.
3. onClick button open de browser (zonder adresbalk / attributen).
4. website.nl/inlogcheck.php?user=[txt_1]&wachtwoord=[txt_2]
5. Kijken of er een record in de DB staat gebruikersnaam en md5(wachtwoord);
6. signaal naar app geven / sessie / cookie zetten ?
7. app browser doorsturen naar index.

Is dit logisch, gaat dit werken, wat zijn de valkuilen ?

Ik ben erg benieuwd naar jullie reacties!

[- peter -]

Wat betreft Android, daar kan je natuurlijk alles ongeveer in de store zetten, daar word niet gekeurd.

[Bas112]

Klikt goed! Apple is dus stricter, waar zitten de verschillen in? wat mag wel, en wat mag niet (volgens Apple) ?

[PublishedMeteor]

Ik verwacht dat je hier weinig succes mee gaat boeken bij Apple. Naast dat de performance nooit zal worden als een "echte app" die native draait (denk al eens aan het inladen van UI elementen etc.) verwacht Apple ook echt dat je app iets toevoegt ten opzichte van een mobiele website. Zie de guidelines:

quote: https://developer.apple.com/app-store/review/guidelines/

4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn't provide some sort of lasting entertainment value, or is just plain creepy, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes store. Apps that are simply a book or game guide should be submitted to the iBooks Store.

Ik weet niet om wat voor website het gaat, maar met bijvoorbeeld en platform als Ionic kun je als webdeveloper al vrij eenvoudig een app schrijven die je daarna cross-platform kunt uitrollen (styling in html/css en de logica programmeren in Javascript, dit koppel je vervolgens via Angular bindings). Dit zal wel iets van een API vereisen aan de server kant om data te verzorgen voor de app.

Overigens verwacht ik inderdaad dat het in de Play Store geen enkele issue zal vormen, daar komt praktisch alles doorheen

[Inspector]

Voor zover ik in de play Store zie, zijn die er momenteel niet meer. Ze waren er wel overigens en zolang er geen officieel logo gevoerd wordt en geen advertenties worden ingebouwd heeft ook Tweakers zelf er niet direct problemen mee. Zowel legal als technisch kan het dus prima

Wel vraag ik me af waarom je dit praktischer vind dan simpelweg in chrome de optie (add to homescreen). Deze maakt een app like shortcut op je homescreen waarna je borderless de site kunt gebruiken.

[Rikkiz0r]

MD5 als wachtwoord hashes lijkt mij ook niet zo'n goed idee...

[Bas112]

@rikkiz0r: Dit was om aan te kaarten dat het versleuteld is, in de praktijk gaat het om de Laravel encryptie.
Volgens mij is md5(); nog steeds knapper dan sha1(); en gaat het vooral om de wijze van omgang met md5() binnen het ledensysteem en gebruik van sessies & cookies.

@PublishedMeteor: Duidelijk! goede materie waar ik wat mee kan. echter blijft het dus nog even de vraag of de Play Store hiermee gestopt is.

@inspector: de afweging tussen een investering in een relatief goedkope app (niet native) tegenover gebruikersgemak geef ik de investering de voorkeur.

Tevens zoek ik naar een oplossing om een toestel te koppelen aan het online account, via de instellingen de gebruiker een 4 cijferige pin-code in te voeren voor de applicatie. Inloggen via grote buttons 0 tm 9 = makkelijker dan e-mail (gebruikersnaam) en wachtwoord. Natuurlijk kan dit ook via een website, maar de gegevens blijven denk ik langer van kracht op een toestel: eenmalig e-mail, en wachtwoord en vervolgens inloggen met de pin-code.

[qless]

md5 is veel zwakker dan sha1

[Rikkiz0r]

Bovendien worden wachtwoorden niet ge-encrypt maar gehashed.

[Barryvdh]

Ik heb ook apps gepubliceerd die direct naar de website verwijzen.
Sommige met soort splash page op index.html (waar iets stond als 'verbinding controleren..') en dan redirect naar de responsive website wanneer er internet is, anders een foutmelding.
Sommige gewoon met <content src="https://website.nl/" /> in de config.xml van cordova, dus die open direct de externe url (responsive website).
Zijn allemaal goedgekeurd. Vroeger deden ze wel eens moeilijk (vandaar die offline check), maar tegenwoordig niks meer van gehoord. Zolang de website maar responsive is.

In jouw geval kan je dus gewoon een form maken, die POST rechtstreeks naar de website. En dan blijf je gewoon op de website. Of je gaat gewoon direct naar de website en plaats daar je inlogformulier, dan is het precies hetzelfde als een website (met cookies/sessie ed.)

Edit: En als het Laravel is, is het gewoon bcrypt (geen md5/sha1) gehashed (niet encrypted).

Als je in je 'app' je login wil controleren, kan je bijv. JWT (https://jwt.io/) gebruiken, dat is een soort encrypted token, waarin de app de status kan aflezen en die je mee kan sturen om server-side te laten controleren (als je meerdere API requests doet)

[ Voor 17% gewijzigd door Barryvdh op 14-06-2016 09:26 ]

[Bas112]

Barry, bedankt! ik ga deze strategie hanteren en kijken of het er door heen komt.
Krijg je ook specifieke reden voor afkeuring, waar je wat aan hebt ?

[Hydra]

basvandenhooff schreef op dinsdag 14 juni 2016 @ 09:15:
@rikkiz0r: Dit was om aan te kaarten dat het versleuteld is, in de praktijk gaat het om de Laravel encryptie.
Volgens mij is md5(); nog steeds knapper dan sha1();

Ik zou je eens ff heel snel in gaan lezen, en dan vooral op het stuk waarom je beiden niet meer wil gebruiken en voor echt goeie hashes (pbkdf2 / scrypt) wil gaan.

Barryvdh schreef op dinsdag 14 juni 2016 @ 09:20:
Als je in je 'app' je login wil controleren, kan je bijv. JWT (https://jwt.io/) gebruiken, dat is een soort encrypted token, waarin de app de status kan aflezen en die je mee kan sturen om server-side te laten controleren (als je meerdere API requests doet)

Het idee van JWT is niet zozeer dat je app dingen kan controleren. Dat token bevat gewoon je credentials en je back-end kan zonder weer je username/password e.d. te moeten checken die credentials gebruiken. Dit is vooral in stateless systemen nuttig omdat een server waarnaar je de token stuurt (in een header) geen toegang hoeft te hebben op je user database omdat al je rechten in 't token staan. Dit i.t.t. 'standaard' tokens die gerehydrateert moeten worden op de back-end.

Heb er vorig jaar een blogpost over geschreven mocht je geïnteresseerd zijn.

[ Voor 45% gewijzigd door Hydra op 14-06-2016 11:17 ]

[Barryvdh]

Hydra schreef op dinsdag 14 juni 2016 @ 11:12:

[...]


Het idee van JWT is niet zozeer dat je app dingen kan controleren. Dat token bevat gewoon je credentials en je back-end kan zonder weer je username/password e.d. te moeten checken die credentials gebruiken. Dit is vooral in stateless systemen nuttig omdat een server waarnaar je de token stuurt (in een header) geen toegang hoeft te hebben op je user database omdat al je rechten in 't token staan. Dit i.t.t. 'standaard' tokens die gerehydrateert moeten worden op de back-end.

Heb er vorig jaar een blogpost over geschreven mocht je geïnteresseerd zijn.

Ehm, dat blog bevat wel een fundamentele (gevaarlijke) fout, je stelt namelijk incorrect dat het token encrypted is!

Obviously this token is not plain text; that would make it trivial for a client to add an 'admin' claim to it’s set. JWT’s are both encrypted with a secure key (only known to the server) as well as signed. This way the client can’t decrypt or alter the claims in any way. Only the server can decrypt the claims because only the server has the key.

Een JWT token is NIET encrypted. Hij is signed. Dat wil zeggen dat je hem wel kan lezen, maar zodra hij aangepast is, kan je hem niet meer valideren. Vul je voorbeeld token maar eens in op https://jwt.io/#debugger en je krijgt direct de claims te zien, zonder geldig secret. Je kan hem enkel pas verifien als je de goede key hebt.

In de payload kan je dus informatie overdragen, normaal gesproken bijvoorbeeld een User ID en expiration time en evt extra informatie voor je app (maar dat kan ook al los request)
De API kan ook deze payload lezen (als je hem meestuurt) en controleren dat het ID niet veranderd is. Dan weet je dus dat het gaat om de user met dat ID.

Je mag dus NOOIT credentials meesturen, als je daarmee user/pass of secret api tokens bedoeld. Want iedereen kan dat lezen (na base64 decoden). Zie ook https://stormpath.com/blog/jwt-the-right-way

Edit: Overigens heb ik ook een blog over JWT. Voornamelijk over Angular/Socialite, maar laatste stuk gaat over JWT: https://medium.com/@barry...el-socialite-bb05661c0d5c

[ Voor 7% gewijzigd door Barryvdh op 14-06-2016 11:39 ]

[Hydra]

Barryvdh schreef op dinsdag 14 juni 2016 @ 11:36:
Een JWT token is NIET encrypted. Hij is signed. Dat wil zeggen dat je hem wel kan lezen, maar zodra hij aangepast is, kan je hem niet meer valideren. Vul je voorbeeld token maar eens in op https://jwt.io/#debugger en je krijgt direct de claims te zien, zonder geldig secret. Je kan hem enkel pas verifien als je de goede key hebt.

Goed punt. Ik zal het aanpassen. Een JWT token kan een JWE encrypted payload hebben maar dat is in dat geval niet van toepassing.

Goeie feedback trouwens; je bent de eerste die hier (terecht) mee komt

[ Voor 6% gewijzigd door Hydra op 14-06-2016 11:47 ]