thomasaull

Congrats for this update @Sebi I like the direction in which you push this module forward ?️

Doesnt the API Endpoint needs to be `testeapi/api` in this case?

Thanks for the quick fix @Sebi! Are you planning on using the new url hooks in the future? I read about it yesterday and it feels like a much cleaner way to handle the requests to the API endpoint

What you do in your API functions is not different from what you would do in regular ProcessWire templates. Is there anything specific you need help with?

Hey @David Lumm, thanks for your suggestions and PR with improvements. I haven't had the need yet, but it's definitely a function which should be included in the AppApi module for sure.

@benbyf I think that's not possible out of the box with the module. If you really want to use one api key per user you somehow would need to programmatically create them and store a reference on the user. But honestly this doesn't look like a good solution to me. You're free to add any checks in your API functions to restrict certain user/roles from doing things, and that is probably how I would handle this. This way you can leverage the entire ProcessWire API. For example: // Route: /api/publish-page/{id} public static function publishPage($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']); $page = wire('pages')->get($data->id); if(!wire('user')->hasPermission('page-publish', $page)) { throw new Exception('Not-allowed'); // Or use AppApiException here } // Publish page }

@benbyf I see… I guess you'll have to wait for an answer from @Sebi for this one That's right actually, I just checked the source, apparently there is no way to access the API without an API Key. The `auth` option only says, if a guest is allowed to access the endpoint. What's holding you back to use an API Key? I think the way to do it is to generate a new API Key for the new version. As soon as the client for the new version is released you can delete the old version. The clients which are still on the old version will get an Error like "API Key not valid" or similar which you can use in your client to guide the user to do whatever you want from there ?

@benbyf I'm going to try to give you some answers: What do you mean by „the log wasn't created for this module"? Can you clarify your question a bit? You can disable auth for certain routes by setting `"auth" => false` in the route options. This is not explicitly documented at the moment, but here is an example where it's set to true: https://github.com/Sebiworld/AppApi#example-listing-users Version numbers are a way to make breaking changes to your API and check for that in the client (e.g. if the client requests API v1 but the newer v2 should be used you can return a warning which the client displays to the user (e.g. to update the software, refresh the website, …) API Keys are way to guard your API to only be accessed by your apps. This is not possible in the browser, since the code would be readable but certainly for complied Apps If you want to restrict API access of certain user roles (`superadmin` is allowed more than `editor`) you'll have to add this logic by yourself in the route methods (it's basically ProcessWire API from there)

I got it working by using the ProcessWire Namespace in my php files: <?php namespace ProcessWire; echo 'break here'; echo 'this is after the breakpoint; I believe this way the files don't get compiled to the cache directory, which apparently causes the breakpoints to get lost

Hey everyone, there is a new module AppApi available which is based on my original RestApi module but has some additional features which are really cool! I have been struggling to find time for the RestApi module over the course of the last 1+ year, so I'm really glad @Sebi is stepping in and doing work in this area. I think it would be a good idea, to see AppApi as a successor of the RestApi module and put all focus and development efforts there. What do you guys think?

@Sebi I created issues for my requests except the API Keys question (I thought this might have been a low hanging fruit, but it looks like it's a bit more complicated)

Two more things: Can you enable Issues in your respository on github? I'm getting an error in this line: https://github.com/Sebiworld/AppApi/blob/master/classes/Router.php#L275 Changing it to if ($last_error && $last_error['type'] === E_ERROR) { fixes it. (This was already suggested by someone some time ago on the RestApi module). I was providing a PR, but since AppApi is a fork of RestApi, when I try to fork it, it just goes back to my module ?

Another thing which would make usage of this module easier for users of the RestApi module would be to have an option to not have to use ApiKeys to access the API

I already have the first request: I was planning to, instead using a hook to intercept the request to play out the api it would be better to (again) use a page in the regular ProcessWire tree for the following reasons: Multi Language does not work with the current solution Caching with ProCache does not work with the current solution It is harder for users of the API module to use Subdirectories Also another request by a user was to move the API routes in `/templates` so it would be included in exports with the site profile export module.

Yeah this is pretty awesome! Since I'm struggeling with carving out time for the RestApi module over the last year (sorry again for not giving your PR much love @Sebi) I'm pretty happy someone is pushing things forward :) Actually I'm thinking maybe this module should be the official continuation of my RestApi Module. For me it looks like it is more advanced and as far as I can tell by creating a single endpoint the way things are used would be quite similar. What do you think? I'm gonna check it out myself now :)

Hey @blackeye, the easiest way to install the module to, in the ProcessWire backend, go to modules -> new and paste the module name "RestApi" in the input at "Add module from directory". After installing you usually don't need to copy any files!

Hi @Orkun, at the moment there is not built-in way for such a use case. However I guess it's really easy to do with a ProcessWire Hook which can be independet of the API, you'd just need to run the hook on the endpoint-url and check the IP with PHP there. If you want to restrict access to specific routes of the API only, I'd probably run the same checks in the endpoint function.

@Andy I think for the getallheaders() function it'd make sense to keep the old way aswell and just search in both for the Authorization Header (If I remember correctly, the getallheaders() function wasn't available in all environments. In case you create a PR we can discuss the details there ? Basically you need to fork the repository, push your changes and then create a PR on the github website

@Andy I'd be awesome if you could create a Pull Request for these changes ?: https://github.com/thomasaull/RestApi/pulls

@Andy Uh, the first time I'm seeing this page. Where can I access it in the ProcessWire Backend? Is the module otherwise working for you? Regarding your question about file uploads: The module itself does not has an implementation for this case, basically it provides just a wrapper for your own functions. So in theory you should be able to create a route for a file upload and have your own function to accept the file and store it on the server. If you google "Processwire file upload" you should find some examples to get you started. I'm writing "in theory" because I haven't done it myself yet. If this approach fails, we can figure out what needs be changed in the module itself.

Ah sorry, I didn't catch that. Can you check in the `headers` Tab how the Header is actually set? I did check everything with Insomnia on Saturday and it worked for me … Regarding saving the JWT Token: I have been saving it in local storge, but this is considered unsafe, since third party scripts could access it (if you do not use any third party scripts, this might not be an issue). So I guess the best thing is to store it in a cookie.

@Orkun Please check the documentation:https://github.com/thomasaull/RestApi#authorization-jwt You need to set the JWT as Header name "Authorization"

Hey @Orkun, thanks, I'm really glad this module is useful for you! The problem you run into, results from code I just copied from @LostKobrakai I think (Thx for investigating btw!). I'm not sure if it's a good way to forward your parameter like this and I guess there's a good reason this sanitizer is in place. Imagine a user would input an email like this `user?foo=bar@test.de`, I guess it would break the API since `foo` would be interpretet as a GET Variable. A couple of suggestions: Use a post request and put the email in the post body URL encode your request url, this way the email *should* come through Maybe other people have some input on this issue aswell…?

@calago I just tried to reproduce this issue with a new installation of ProcessWire: Install ProcessWire with blank profile Install RestApi Module run `api/test` => `test successful` change endpoint to `api-v2` run `api/test` => 404 Error run `api-v2/test` => `test successful` comment out all routes in `Routes.php` and run `api-v2/test` => 500 Server error (this is expected I guess) Add new file `/site/api/AnotherExample.php`, change `Routes.php` to this: <?php namespace ProcessWire; require_once wire('config')->paths->RestApi . "vendor/autoload.php"; require_once wire('config')->paths->RestApi . "RestApiHelper.php"; require_once __DIR__ . "/AnotherExample.php"; $routes = [ ['GET', 'other-test', AnotherExample::class, 'other'], ]; and run `api-v2/other-test` => `another example` So basically everything is working perfectly fine on my end. I guess it's something related to your environment/installation/modules… Hard to debug, if you need more help maybe provide a test repo?

Mmmhh really weird. Can‘t spot anything wrong on first sight. Can you reproduce this problem on a fresh install without any other plugins? Are you using anything cache related (Pro-Cache maybe?)