Update jdk

README.md

@@ -108,3 +108,4 @@ and verify response status is `200 OK`.
 - [Code Style](docs/code-style.md)
 - [Code Review](docs/code-reviews.md)
 - [Versioning](docs/versioning.md)
+

build/Dockerfile

@@ -0,0 +1,25 @@
+FROM --platform=amd64 tomcat:8.5-jdk8-temurin-jammy
+
+ENV VERTICLE_FILE prebid-server.jar
+
+# Set the location of the verticles
+ENV VERTICLE_HOME /usr/verticles
+
+#EXPOSE 5000
+
+# Copy your fat jar to the container
+COPY ./target/$VERTICLE_FILE $VERTICLE_HOME/
+RUN mkdir -p /var/log/mbid/
+
+# Launch the verticle
+WORKDIR $VERTICLE_HOME
+# Add Tini
+ENV TINI_VERSION v0.18.0
+ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static /tini
+RUN chmod +x /tini
+
+ENTRYPOINT ["/tini", "--"]
+
+
+#It will be overwritten
+CMD ["exec java -Dlogging.config=logback.xml -jar prebid-server.jar --debug --spring.config.location=classpath:/application.yaml,prebid-config.yaml"]

docs/config-app.md

@@ -118,16 +118,30 @@ Removes and downloads file again if depending service cant process probably corr
 There are several typical keys:
 - `adapters.<BIDDER_NAME>.enabled` - indicates the bidder should be active and ready for auction. By default all bidders are disabled.
 - `adapters.<BIDDER_NAME>.endpoint` - the url for submitting bids.
-- `adapters.<BIDDER_NAME>.pbs-enforces-gdpr` - indicates if pbs server provides gdpr support for bidder or bidder will handle it itself.
+- `adapters.<BIDDER_NAME>.pbs-enforces-gdpr` - indicates if PBS server provides GDPR support for bidder or bidder will handle it itself.
+- `adapters.<BIDDER_NAME>.pbs-enforces-ccpa` - indicates if PBS server provides CCPA support for bidder or bidder will handle it itself.
+- `adapters.<BIDDER_NAME>.modifying-vast-xml-allowed` - indicates if PBS server is allowed to modify VAST creatives received from this bidder.
 - `adapters.<BIDDER_NAME>.deprecated-names` - comma separated deprecated names of bidder.
-- `adapters.<BIDDER_NAME>.aliases` - comma separated aliases of bidder.
+- `adapters.<BIDDER_NAME>.meta-info.maintainer-email` - specifies maintainer e-mail address that will be shown in bidder info endpoint response.
+- `adapters.<BIDDER_NAME>.meta-info.app-media-types` - specifies media types supported for app requests that will be shown in bidder info endpoint response.
+- `adapters.<BIDDER_NAME>.meta-info.site-media-types` - specifies media types supported for site requests that will be shown in bidder info endpoint response.
+- `adapters.<BIDDER_NAME>.meta-info.supported-vendors` - specifies viewability vendors supported by the bidder.
+- `adapters.<BIDDER_NAME>.meta-info.vendor-id` - specifies TCF vendor ID.
 - `adapters.<BIDDER_NAME>.usersync.url` - the url for synchronizing UIDs cookie.
 - `adapters.<BIDDER_NAME>.usersync.redirect-url` - the redirect part of url for synchronizing UIDs cookie.
 - `adapters.<BIDDER_NAME>.usersync.cookie-family-name` - the family name by which user ids within adapter's realm are stored in uidsCookie.
 - `adapters.<BIDDER_NAME>.usersync.type` - usersync type (i.e. redirect, iframe).
 - `adapters.<BIDDER_NAME>.usersync.support-cors` - flag signals if CORS supported by usersync.
 
-But feel free to add additional bidder's specific options.
+In addition, each bidder could have arbitrary aliases configured that will look and act very much the same as the bidder itself.
+Aliases are configured by adding child configuration object at `adapters.<BIDDER_NAME>.aliases.<BIDDER_ALIAS>.`, aliases 
+support the same configuration options that their bidder counterparts support except `aliases` (i.e. it's not possible 
+to declare alias of an alias). Another restriction of aliases configuration is that they cannot declare support for media types 
+not supported by their bidders (however aliases could narrow down media types they support). For example: if the bidder 
+is written to not support native site requests, then an alias cannot magically decide to change that; however, if a bidder 
+supports native site requests, and the alias does not want to for some reason, it has the ability to remove that support.
+
+Also, each bidder could have its own bidder-specific options.
 
 ## Logging
 - `logging.http-interaction.max-limit` - maximum value for the number of interactions to log in one take.

docs/developers/add-new-bidder.md

@@ -23,7 +23,7 @@ your bidder will access them at `request.imp[i].ext.bidder`--regardless of what
 ## Configuration
 
 Add default configuration properties and metadata(e.g. contact email, platform & media type support) for your Bidder to `src/main/resources/bidder-config/{bidder}.yaml` file.
-For more information about application configuration see [here](../config.md)
+For more information about application configuration see [here](../config-app.md)
 
 ## Implementation
 
@@ -100,7 +100,8 @@ It should be public class with Spring `@Configuration` annotation so that framew
 This file consists of three main parts:
 - the constant `BIDDER_NAME` with the name of your Bidder.
 - injected configuration properties (like `endpoint`, `usersyncUrl`, etc) needed for the Bidder's implementation.
-- declaration of `BidderDeps` bean combining _bidder name_, _Usersyncer_ and _BidderRequester_ in one place as a single point-of-truth for using it in application.
+- declaration of `BidderDeps` bean combining _bidder name_, _Usersyncer_, _Adapter_, _Bidder_ and other meta-data 
+for the bidder and its aliases in one place as a single point-of-truth for using it in application.
 
 Also, you can add `@ConditionalOnProperty` annotation on configuration if bidder has no default properties.
 See `src/main/java/org/prebid/server/spring/config/bidder/FacebookConfiguration.java` as an example.
@@ -122,7 +123,7 @@ Commonly you should write tests for covering:
 - specific cases for composing requests to exchange.
 - specific cases for processing responses from exchange.
 
-Do not forget to add your Bidder to `ApplicationTest.java` tests.
+Do not forget to add integration test for your Bidder in `src/test/java/org/prebid/server/it`.
 
 We expect to see at least 90% code coverage on each bidder.
 

docs/endpoints/cookieSync.md

@@ -9,13 +9,23 @@ This endpoint is used during cookie syncs. For technical details, see the
 This returns a set of URLs to enable cookie syncs across bidders. (See Prebid.js documentation?) The request
 must supply a JSON object to define the list of bidders that may need to be synced.
 
-```
+```json
 {
     "bidders": ["appnexus", "rubicon"],
     "coopSync": true,
     "gdpr": 1,
     "gdpr_consent": "BONV8oqONXwgmADACHENAO7pqzAAppY",
-    "limit": 2
+    "limit": 2,
+    "filterSettings": {
+        "iframe": {
+            "bidders": ["rubicon"], // only this bidder is excluded from syncing iframe pixels, all other bidders are allowed
+            "filter": "exclude"
+        },
+       "image": {
+            "bidders": ["appnexus"], //only this bidder is allowed to sync image pixels
+            "filter": "include"
+       }
+    }
 }
 ```
 
@@ -31,6 +41,8 @@ must supply a JSON object to define the list of bidders that may need to be sync
 get the count down to limit if more would otherwise have been returned. This is to facilitate clients not overloading a user with syncs
 the first time they are encountered.
 
+`filterSettings` is optional. It defines which bidders are allowed to use which usersync method. 
+
 If `gdpr` is  omitted, callers are still encouraged to send `gdpr_consent` if they have it.
 Depending on how the Prebid Server host company has configured their servers, they may or may not require it for cookie syncs.
 

docs/endpoints/setuid.md

@@ -13,7 +13,7 @@ This endpoint saves a UserID for a Bidder in the Cookie. Saved IDs will be recog
 - `uid`: The ID which the Bidder uses to recognize this user. If undefined, the UID for `bidder` will be deleted.
 - `gdpr`: This should be `1` if GDPR is in effect, `0` if not, and undefined if the caller isn't sure
 - `gdpr_consent`: This is required if `gdpr` is one, and optional (but encouraged) otherwise. If present, it should be an [unpadded base64-URL](https://tools.ietf.org/html/rfc4648#page-7) encoded [Vendor Consent String](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md#vendor-consent-string-format-).
-- `format`: is optional. When `format=img`, response will include `tracking-pixel.png` file.
+- `f`: is optional. When `f=i`, response will include `tracking-pixel.png` file, when `f=b` respond with empty html, content-length=0 and text/html content type.
 
 If the `gdpr` and `gdpr_consent` params are included, this endpoint will _not_ write a cookie unless:
 

docs/metrics.md

@@ -115,6 +115,8 @@ Following metrics are collected and submitted if account is configured with `det
 - `usersync.bad_requests` - number of requests received with bidder not specified
 - `usersync.<bidder-name>.sets` - number of requests received resulted in `uid` cookie update for `<bidder-name>`
 - `usersync.<bidder-name>.tcf.blocked` - number of requests received that didn't result in `uid` cookie update for `<bidder-name>` because of lack of user consent for this action according to TCF
+- `usersync.<bidder-name>.tcf.invalid` - number of requests received that are lacking of a valid consent string for `<bidder-name>` in setuid endpoint
+- `usersync.all.tcf.invalid` - number of requests received that are lacking of a valid consent string for all requested bidders cookieSync endpoint
 
 ## Privacy metrics
 - `privacy.tcf.(missing|invalid)` - number of requests lacking a valid consent string