This project does not seem to handle request data directly as such no vulnerable execution paths were found.
include
, or for example
via PHP's auto-loading mechanism.
These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more
1 | <?php |
||
2 | |||
3 | |||
4 | return [ |
||
5 | |||
6 | /* |
||
7 | |-------------------------------------------------------------------------- |
||
8 | | Standards Tree |
||
9 | |-------------------------------------------------------------------------- |
||
10 | | |
||
11 | | Versioning an API with Dingo revolves around content negotiation and |
||
12 | | custom MIME types. A custom type will belong to one of three |
||
13 | | standards trees, the Vendor tree (vnd), the Personal tree |
||
14 | | (prs), and the Unregistered tree (x). |
||
15 | | |
||
16 | | By default the Unregistered tree (x) is used, however, should you wish |
||
17 | | to you can register your type with the IANA. For more details: |
||
18 | | https://tools.ietf.org/html/rfc6838 |
||
19 | | |
||
20 | */ |
||
21 | |||
22 | 'standardsTree' => env('API_STANDARDS_TREE', 'x'), |
||
23 | |||
24 | /* |
||
25 | |-------------------------------------------------------------------------- |
||
26 | | API Subtype |
||
27 | |-------------------------------------------------------------------------- |
||
28 | | |
||
29 | | Your subtype will follow the standards tree you use when used in the |
||
30 | | "Accept" header to negotiate the content type and version. |
||
31 | | |
||
32 | | For example: Accept: application/x.SUBTYPE.v1+json |
||
33 | | |
||
34 | */ |
||
35 | |||
36 | 'subtype' => env('API_SUBTYPE', ''), |
||
37 | |||
38 | /* |
||
39 | |-------------------------------------------------------------------------- |
||
40 | | Default API Version |
||
41 | |-------------------------------------------------------------------------- |
||
42 | | |
||
43 | | This is the default version when strict mode is disabled and your API |
||
44 | | is accessed via a web browser. It's also used as the default version |
||
45 | | when generating your APIs documentation. |
||
46 | | |
||
47 | */ |
||
48 | |||
49 | 'version' => env('API_VERSION', 'v1'), |
||
50 | |||
51 | /* |
||
52 | |-------------------------------------------------------------------------- |
||
53 | | Default API Prefix |
||
54 | |-------------------------------------------------------------------------- |
||
55 | | |
||
56 | | A default prefix to use for your API routes so you don't have to |
||
57 | | specify it for each group. |
||
58 | | |
||
59 | */ |
||
60 | |||
61 | 'prefix' => env('API_PREFIX', null), |
||
62 | |||
63 | /* |
||
64 | |-------------------------------------------------------------------------- |
||
65 | | Default API Domain |
||
66 | |-------------------------------------------------------------------------- |
||
67 | | |
||
68 | | A default domain to use for your API routes so you don't have to |
||
69 | | specify it for each group. |
||
70 | | |
||
71 | */ |
||
72 | |||
73 | 'domain' => env('API_DOMAIN', null), |
||
74 | |||
75 | /* |
||
76 | |-------------------------------------------------------------------------- |
||
77 | | Name |
||
78 | |-------------------------------------------------------------------------- |
||
79 | | |
||
80 | | When documenting your API using the API Blueprint syntax you can |
||
81 | | configure a default name to avoid having to manually specify |
||
82 | | one when using the command. |
||
83 | | |
||
84 | */ |
||
85 | |||
86 | 'name' => env('API_NAME', null), |
||
87 | |||
88 | /* |
||
89 | |-------------------------------------------------------------------------- |
||
90 | | Conditional Requests |
||
91 | |-------------------------------------------------------------------------- |
||
92 | | |
||
93 | | Globally enable conditional requests so that an ETag header is added to |
||
94 | | any successful response. Subsequent requests will perform a check and |
||
95 | | will return a 304 Not Modified. This can also be enabled or disabled |
||
96 | | on certain groups or routes. |
||
97 | | |
||
98 | */ |
||
99 | |||
100 | 'conditionalRequest' => env('API_CONDITIONAL_REQUEST', true), |
||
101 | |||
102 | /* |
||
103 | |-------------------------------------------------------------------------- |
||
104 | | Strict Mode |
||
105 | |-------------------------------------------------------------------------- |
||
106 | | |
||
107 | | Enabling strict mode will require clients to send a valid Accept header |
||
108 | | with every request. This also voids the default API version, meaning |
||
109 | | your API will not be browsable via a web browser. |
||
110 | | |
||
111 | */ |
||
112 | |||
113 | 'strict' => env('API_STRICT', false), |
||
114 | |||
115 | /* |
||
116 | |-------------------------------------------------------------------------- |
||
117 | | Debug Mode |
||
118 | |-------------------------------------------------------------------------- |
||
119 | | |
||
120 | | Enabling debug mode will result in error responses caused by thrown |
||
121 | | exceptions to have a "debug" key that will be populated with |
||
122 | | more detailed information on the exception. |
||
123 | | |
||
124 | */ |
||
125 | |||
126 | 'debug' => env('API_DEBUG', false), |
||
127 | |||
128 | /* |
||
129 | |-------------------------------------------------------------------------- |
||
130 | | Generic Error Format |
||
131 | |-------------------------------------------------------------------------- |
||
132 | | |
||
133 | | When some HTTP exceptions are not caught and dealt with the API will |
||
134 | | generate a generic error response in the format provided. Any |
||
135 | | keys that aren't replaced with corresponding values will be |
||
136 | | removed from the final response. |
||
137 | | |
||
138 | */ |
||
139 | |||
140 | 'errorFormat' => [ |
||
141 | 'message' => ':message', |
||
142 | 'errors' => ':errors', |
||
143 | 'code' => ':code', |
||
144 | 'status_code' => ':status_code', |
||
145 | 'debug' => ':debug', |
||
146 | ], |
||
147 | |||
148 | /* |
||
149 | |-------------------------------------------------------------------------- |
||
150 | | API Middleware |
||
151 | |-------------------------------------------------------------------------- |
||
152 | | |
||
153 | | Middleware that will be applied globally to all API requests. |
||
154 | | |
||
155 | */ |
||
156 | |||
157 | 'middleware' => [ |
||
158 | |||
159 | ], |
||
160 | |||
161 | /* |
||
162 | |-------------------------------------------------------------------------- |
||
163 | | Authentication Providers |
||
164 | |-------------------------------------------------------------------------- |
||
165 | | |
||
166 | | The authentication providers that should be used when attempting to |
||
167 | | authenticate an incoming API request. |
||
168 | | |
||
169 | */ |
||
170 | |||
171 | 'auth' => [ |
||
172 | 'passport' => \Milkmeowo\Framework\Dingo\Auth\Providers\Passport::class, |
||
173 | //'oauth' => Milkmeowo\Framework\Dingo\Auth\Providers\OAuth2::class, |
||
0 ignored issues
–
show
|
|||
174 | //'jwt' => Dingo\Api\Auth\Provider\JWT::class, |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
50% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
175 | ], |
||
176 | |||
177 | /* |
||
178 | |-------------------------------------------------------------------------- |
||
179 | | Throttling / Rate Limiting |
||
180 | |-------------------------------------------------------------------------- |
||
181 | | |
||
182 | | Consumers of your API can be limited to the amount of requests they can |
||
183 | | make. You can create your own throttles or simply change the default |
||
184 | | throttles. |
||
185 | | |
||
186 | */ |
||
187 | |||
188 | 'throttling' => [ |
||
189 | |||
190 | ], |
||
191 | |||
192 | /* |
||
193 | |-------------------------------------------------------------------------- |
||
194 | | Response Transformer |
||
195 | |-------------------------------------------------------------------------- |
||
196 | | |
||
197 | | Responses can be transformed so that they are easier to format. By |
||
198 | | default a Fractal transformer will be used to transform any |
||
199 | | responses prior to formatting. You can easily replace |
||
200 | | this with your own transformer. |
||
201 | | |
||
202 | */ |
||
203 | |||
204 | 'transformer' => env('API_TRANSFORMER', Dingo\Api\Transformer\Adapter\Fractal::class), |
||
205 | |||
206 | /* |
||
207 | |-------------------------------------------------------------------------- |
||
208 | | Response Formats |
||
209 | |-------------------------------------------------------------------------- |
||
210 | | |
||
211 | | Responses can be returned in multiple formats by registering different |
||
212 | | response formatters. You can also customize an existing response |
||
213 | | formatter. |
||
214 | | |
||
215 | */ |
||
216 | |||
217 | 'defaultFormat' => env('API_DEFAULT_FORMAT', 'jsonp'), |
||
218 | |||
219 | 'formats' => [ |
||
220 | |||
221 | 'json' => Dingo\Api\Http\Response\Format\Json::class, |
||
222 | |||
223 | 'jsonp' => Dingo\Api\Http\Response\Format\Jsonp::class, |
||
224 | |||
225 | ], |
||
226 | |||
227 | ]; |
||
228 |
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.
The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.
This check looks for comments that seem to be mostly valid code and reports them.