thomasaull

Members
  • Content Count

    41
  • Joined

  • Last visited

  • Days Won

    2

thomasaull last won the day on September 19 2018

thomasaull had the most liked content!

Community Reputation

78 Excellent

About thomasaull

  • Rank
    Jr. Member

Recent Profile Visitors

1,223 profile views
  1. thomasaull

    @pwFoo What exactely do you mean by 1)? Mapping an endpoint to a PW Page is as easy as $page = wire('pages')->get(1042); in your endpoint function. Mapping an endpoint to a php file is the intendend behaviour of the module, check the example: https://github.com/thomasaull/RestApi/blob/master/apiTemplate/Example.php which get's mapped in the Routes.php: https://github.com/thomasaull/RestApi/blob/master/apiTemplate/Routes.php 2) That's basically the approach @LuisM used in his PR. I'm not sure if it's the best solution, check my comment on Github: https://github.com/thomasaull/RestApi/pull/1#issuecomment-450135767
  2. thomasaull

    Oh dear! Thanks @BitPoet that's the solution I actually just missed to update the version in info.json…
  3. I tried to update the RestApi Module (http://modules.processwire.com/modules/rest-api/) from 0.0.3 to 0.0.4 without success. I updated everything on Github, published a new release over there and tried the following: wait couple of days for the module to update itself automatically input the new version number manually – after saving the version just stays the same Dunno if I'm doing something wrong or if it's broken?
  4. thomasaull

    Thanks Thorsten! How you handle incoming api requests is generally totally up to you – you have all the freedom Your idea sounds like a good and easy solution though. However, currently there is no possibility to implement such thing globally on every request. For this maybe it would be a good idea to make the handle() method in Router.php hookable. Maybe you want to test it and provide a PR for this. It would be very welcome For Session auth just activate the option in the module settings and make sure to provide the withCredentials option: https://github.com/thomasaull/RestApi/blob/master/README.md#authorization-session. In your frontend app just send a login request to the auth endpoint: https://github.com/thomasaull/RestApi/blob/master/README.md#authorization-jwt and it should (hopefully) work
  5. thomasaull

    You're totally right, good catch thank you! I updated the Readme accordingly.
  6. thomasaull

    @LuisM Hey Luis, yes I saw it on Github. I'm a little short on time from last week to in a few days, I'm going to get back at you at the PR as soon as possible!
  7. thomasaull

    @eelkenet Thanks for using this module and I'm glad it is useful to you This is actually the first time, I've heard about the @Operator regarding errors. However, I found an interesting paragraph on the page you have linked to in your post: So I added a line, which checks for the error reporting before displaying an error: https://github.com/thomasaull/RestApi/commit/fe63cc48cfcc6d58489f019d5026764cb60d14e5 Could you please manually download the module from the develop branch on Github and give me quick feedback if this resolves your issue? https://github.com/thomasaull/RestApi/archive/develop.zip
  8. thomasaull

    I actually stumbled upon these two articles when I did some resarch on saturday and I think I'm getting your point. However I don't agree with all of the statements made there: On the flow chart on the far right it says “I'll just use refresh tokens" which he states couldn't be revoked – afaik usually you save the refresh token in the datebase of your Auth Server and everytime a user wants to refresh a token you check if it is still valid. So e.g. you could hand out short lived tokens (like 5-10 minutes) and everytime it expires the client has to obtain a new token via the refresh token if it's not revoked. In an upcoming project we might have multiple endpoints for different task, where it just sounded good to have an Auth Server which holds all the user information and hands out tokens, which the client uses on the other server to access something. On "Footnote: microservice architectures" of part 2 the autor suggests to use single use tokens to get a session on the other service, which I think means, If I want to revoke a session I need to do it on multiple places right? Aaaanyway, I did some tests with the API Module, sessions and a cross-origin client and it also works quite well, so with 0.0.3 you can choose your auth method in module settings between none / session / jwt
  9. thomasaull

    Thank you @teppo A configurable endpoint ist not really difficult, so I just did it – 0.0.2 has a field in the module settings for that
  10. thomasaull

    Absolutely true. So what would be a feasable Alternative then if I don‘t want to use sessions? Say, because of multiple services (where the alternative would be to store alle the user data on every service)
  11. thomasaull

    Thanks for your input @LostKobrakai , that's exactely why I put this up, since it's a security sensitive topic. Again I'm not an expert on JWT, but I thought that's what the „exp" Parameter is for? In the module it's set to the "sessionExpireSeconds" of PWs config (which is 24h I think). I made a quick test and set it to 2 minutes and while it worked at first after a couple of minutes I got an Error: "Error: Exception: Expired token". So I guess you're right, there is no way to revoke its validity but on the other hand it seems like it's not valid forever (at least if you don't set it to be)
  12. thomasaull

    Thanks @bernhard! The API does not really care if it's served over http or https, it's just HTTP(s)-Requests after all. If your server is configured to redirect all http requests to https, it'll do so with these as well. However, it's always a bit of a hazzle to test locally, so I left the examples as is and put a note that it's a good idea to use https JWT Auth (in this case) works like the following: The client sends a login-request with username + password (this definitely should go over HTTPS) The server checks the login credentials and if correct, creates a unique token with an added encrypted signature The client uses this token to authentiate every following request Since the client does not know the secret, he cannot modify the contents of the token without making it invalid That's basically how I understood it
  13. thomasaull

    It is ready for testing now:
  14. thomasaull

    @nicolant had some problems to get the old site profile working with different domains for api and client: It should work out of the box with the module, but apparently you need to add an OPTIONS route for every endpoint. I could automate this, but don't know if it's a good idea to do this for every route, since I'm not an expert on this CORS / preflight. Opinions?
  15. thomasaull

    Some time ago I created a site profile for creation of a REST API with ProcessWire. Since I kept struggeling with updating stuff between different projects which use this, I decided to convert it into a module. It is now ready for testing: https://github.com/thomasaull/RestApi Additionally I added a few small features: automatic creation of JWT Secret at module install routes can be flagged as auth: false, which makes them publicly accessible even though JWT Auth is activated in module settings To check things out, download and install the module and check the folder /site/api for examples. If you find any bugs or can think of improvements, please let me know!