• Content Count

  • Joined

  • Last visited

  • Days Won


thomasaull last won the day on September 19

thomasaull had the most liked content!

Community Reputation

73 Excellent

About thomasaull

  • Rank
    Jr. Member

Recent Profile Visitors

1,128 profile views
  1. 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
  2. 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
  3. 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)
  4. 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)
  5. 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
  6. thomasaull

    It is ready for testing now:
  7. 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?
  8. 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: 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!
  9. thomasaull

    Also just as a heads up, I'm in the process of converting this site profile into a module, since I'm struggeling to keep it up to date on my sites and thus should be much easier to update in the future
  10. thomasaull

    @gebeer you can also try to replace apache_request_headers() with $_SERVER which should also work. This way you don't need the any additional functions
  11. thomasaull

    The auth() and login() functions are usually just used once to login a user and obtain an JWT token. The token is currently stored in vuex and will be lost on reload. The /client folder is also just intended to get you started and give you a general idea how the jwt login process could work. Anyway I think you figured it out by now
  12. thomasaull

    while the wire('session')->login() should work for this request, it is likely the session is already destroyed on the next one. For this case it might be feasible to store the user id in the jwt payload (like you suggested). Since I'm going to have this case in an upcoming project, I gave it a try this morning. Please check the following commit for the changes I did: I didn't test it with different domains though, so I'd be thankful if you could report back if it works for you!
  13. thomasaull

    Glad you figured it out! I think I ran into the same issue on another project earlier and I solived it like you by using "Alternate Template Filename". Since the frontend of a Vue App would be completely decoupled from ProcessWire anyway, another possible solution would be to set every page to "hidden" except the home page (didn't try that though). Edit: An that probably wouldn't allow deep linking on initial page load
  14. thomasaull

    If it works for the login, it should work with every other route aswell. Did you create the route in /router/index.js? And are you trying to use HTML5 History Mode?
  15. thomasaull

    @psy I (hopefully) resolved all issues with an update to the site profile. Can you give it a try and check if everything is working for you now? I didn't want to copy all the sanitizers in my site profile since it might break, when there will be more sanitizers added in the future. Instead I'm checking with method_exists if the specified sanitizer exists. Thanks for all your input and work