thomasaull
-
Posts
95 -
Joined
-
Last visited
-
Days Won
2
Everything posted by 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
-
You're totally right, good catch thank you! I updated the Readme accordingly.
-
@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!
-
@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
-
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
-
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 ?
-
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)
-
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)
-
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 ?
-
It is ready for testing now:
-
@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?
-
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!
- 120 replies
-
- 17
-
-
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
-
@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
-
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 ?
-
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: https://github.com/thomasaull/RestApiProfile-Src/commit/2dbdc79aa952bece6926dbee896de0a4f434bb6a I didn't test it with different domains though, so I'd be thankful if you could report back if it works for you! ?
-
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
-
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?
-
@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? https://github.com/thomasaull/RestApiProfile/releases/tag/0.1.1 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
-
Ok so apparently my flight got wifi, so I'm able to answer now Vue Router is also capable of suppressing the /#/ in URLs, you just need to add the HTML5 History Mode: https://router.vuejs.org/en/essentials/history-mode.html Did you actually check and run the Vue Login example? Is everything working as supposed there? The login does happen in the login function in Auth.php, the other function just makes sure the user is actually logged in and therefore allowed to query the API. $authActive never gets changed after the initial declaration, it's basically just a switch to make the API publicy available or not. To get rid of the errors by TracyDebugger you can just delete these lines, they are just in there for debugging. You can totally have multiple Vue SPAs querying the same API, although I have never tested this with this profile. There might be CORS related issues that needs to be solved first. For starters, I'd try to have it all under the same domain. The checkAndSanitize works with. name|sanitizer pairs, check this line: https://github.com/thomasaull/RestApiProfile/blob/master/templates/api/Test.php#L17 (message is the parameter you're sending, text is the sanitizer which should be applied) I think I forgot to change the function call in Auth.php, try: ApiHelper::checkAndSanitizeRequiredParameters($data, ['username|text', 'password|text']); Try to change this line, remove all TracyDebugger statements and run the Vue example. I guess it should work then! I'm not with my computer until end of next week, so not really a big help I'm afraid ?
-
Sorry for the hazzle @psy. I‘m on the road atm, how important is this? I can try to get you some assistance maybe later today
-
It's not necessary, just one way of authentication. Basic Auth is perfectly fine aswell
-
Are you working on it? I'm not sure if you need a module for that, the only thing which makes sense being managed by the backend is the JWT Secret maybe… But by all means it might make things easy for people who are not familiar with JWT!
-
Unfortunately, one is not public – the other one not finished (not public either, but I might put in in my portfolio with a screencast or anything)
-
Hey hey, since I took a slightly different approach connecting my SPA with ProcessWire I created a new example site profile. The JWT-Auth stuff is in there, but honestly it's not very complicated, so I guess it could easily implemented anywhere else! Check it out:
- 36 replies
-
- 1
-
-
- vue-router
- vuex
- (and 2 more)
