2017-05-15 04:46:01 +00:00
|
|
|
use std::ops::BitOr;
|
|
|
|
|
2019-06-13 01:48:02 +00:00
|
|
|
/// Information about a [`Fairing`](crate::fairing::Fairing).
|
2017-05-15 04:46:01 +00:00
|
|
|
///
|
|
|
|
/// The `name` field is an arbitrary name for a fairing. The `kind` field is a
|
2018-10-06 13:25:17 +00:00
|
|
|
/// is an `or`d set of [`Kind`] structures. Rocket uses the values set in `Kind`
|
|
|
|
/// to determine which callbacks from a given `Fairing` implementation to
|
|
|
|
/// actually call.
|
2017-05-15 04:46:01 +00:00
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
///
|
|
|
|
/// A simple `Info` structure that can be used for a `Fairing` that implements
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
/// all callbacks:
|
2017-05-15 04:46:01 +00:00
|
|
|
///
|
|
|
|
/// ```
|
|
|
|
/// use rocket::fairing::{Info, Kind};
|
|
|
|
///
|
|
|
|
/// # let _unused_info =
|
|
|
|
/// Info {
|
|
|
|
/// name: "Example Fairing",
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
/// kind: Kind::Launch | Kind::Liftoff | Kind::Request | Kind::Response
|
2017-05-15 04:46:01 +00:00
|
|
|
/// }
|
|
|
|
/// # ;
|
|
|
|
/// ```
|
Test 'secret_key' validation, now on pre-launch.
Prior to this commit, it was not possible to test Rocket crates in
production mode without setting a global secret key or bypassing secret
key checking - the testing script did the latter. The consequence is
that it became impossible to test secret key related failures because
the tests passed regardless.
This commit undoes this. As a consequence, all tests are now aware of
the difference between debug and release configurations, the latter of
which validates 'secret_key' by default. New 'Client::debug()' and
'Client::debug_with()' simplify creating an instance of 'Client' with
configuration in debug mode to avoid undesired test failures.
The summary of changes in this commit are:
* Config 'secret_key' success and failure are now tested.
* 'secret_key' validation was moved to pre-launch from 'Config:from()'.
* 'Config::from()' only extracts the config.
* Added 'Config::try_from()' for non-panicking extraction.
* 'Config' now knows the profile it was extracted from.
* The 'Config' provider sets a profile of 'Config.profile'.
* 'Rocket', 'Client', 'Fairings', implement 'Debug'.
* 'fairing::Info' implements 'Copy', 'Clone'.
* 'Fairings' keeps track of, logs attach fairings.
* 'Rocket::reconfigure()' was added to allow modifying a config.
Internally, the testing script was refactored to properly test the
codebase with the new changes. In particular, it no longer sets a rustc
'cfg' to avoid secret-key checking.
Resolves #1543.
Fixes #1564.
2021-03-09 08:07:43 +00:00
|
|
|
#[derive(Debug, Copy, Clone)]
|
2017-05-15 04:46:01 +00:00
|
|
|
pub struct Info {
|
|
|
|
/// The name of the fairing.
|
|
|
|
pub name: &'static str,
|
|
|
|
/// A set representing the callbacks the fairing wishes to receive.
|
|
|
|
pub kind: Kind
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A bitset representing the kinds of callbacks a
|
2019-06-13 01:48:02 +00:00
|
|
|
/// [`Fairing`](crate::fairing::Fairing) wishes to receive.
|
2017-05-15 04:46:01 +00:00
|
|
|
///
|
|
|
|
/// A fairing can request any combination of any of the following kinds of
|
|
|
|
/// callbacks:
|
|
|
|
///
|
|
|
|
/// * Launch
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
/// * Liftoff
|
2017-05-15 04:46:01 +00:00
|
|
|
/// * Request
|
|
|
|
/// * Response
|
|
|
|
///
|
|
|
|
/// Two `Kind` structures can be `or`d together to represent a combination. For
|
|
|
|
/// instance, to represent a fairing that is both a launch and request fairing,
|
|
|
|
/// use `Kind::Launch | Kind::Request`. Similarly, to represent a fairing that
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
/// is only a launch fairing, use `Kind::Launch`.
|
2017-05-15 04:46:01 +00:00
|
|
|
#[derive(Debug, Clone, Copy)]
|
|
|
|
pub struct Kind(usize);
|
|
|
|
|
|
|
|
#[allow(non_upper_case_globals)]
|
|
|
|
impl Kind {
|
|
|
|
/// `Kind` flag representing a request for a 'launch' callback.
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
pub const Launch: Kind = Kind(1 << 0);
|
|
|
|
|
|
|
|
/// `Kind` flag representing a request for a 'liftoff' callback.
|
|
|
|
pub const Liftoff: Kind = Kind(1 << 1);
|
|
|
|
|
2017-05-15 04:46:01 +00:00
|
|
|
/// `Kind` flag representing a request for a 'request' callback.
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
pub const Request: Kind = Kind(1 << 2);
|
|
|
|
|
2017-05-15 04:46:01 +00:00
|
|
|
/// `Kind` flag representing a request for a 'response' callback.
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
pub const Response: Kind = Kind(1 << 3);
|
2017-05-15 04:46:01 +00:00
|
|
|
|
|
|
|
/// Returns `true` if `self` is a superset of `other`. In other words,
|
|
|
|
/// returns `true` if all of the kinds in `other` are also in `self`.
|
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
///
|
|
|
|
/// ```rust
|
|
|
|
/// use rocket::fairing::Kind;
|
|
|
|
///
|
|
|
|
/// let launch_and_req = Kind::Launch | Kind::Request;
|
|
|
|
/// assert!(launch_and_req.is(Kind::Launch | Kind::Request));
|
|
|
|
///
|
|
|
|
/// assert!(launch_and_req.is(Kind::Launch));
|
|
|
|
/// assert!(launch_and_req.is(Kind::Request));
|
|
|
|
///
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
/// assert!(!launch_and_req.is(Kind::Liftoff));
|
2017-05-15 04:46:01 +00:00
|
|
|
/// assert!(!launch_and_req.is(Kind::Response));
|
|
|
|
/// assert!(!launch_and_req.is(Kind::Launch | Kind::Response));
|
|
|
|
/// assert!(!launch_and_req.is(Kind::Launch | Kind::Request | Kind::Response));
|
|
|
|
/// ```
|
|
|
|
#[inline]
|
|
|
|
pub fn is(self, other: Kind) -> bool {
|
|
|
|
(other.0 & self.0) == other.0
|
|
|
|
}
|
2017-05-17 08:39:36 +00:00
|
|
|
|
|
|
|
/// Returns `true` if `self` is exactly `other`.
|
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
///
|
|
|
|
/// ```rust
|
|
|
|
/// use rocket::fairing::Kind;
|
|
|
|
///
|
|
|
|
/// let launch_and_req = Kind::Launch | Kind::Request;
|
|
|
|
/// assert!(launch_and_req.is_exactly(Kind::Launch | Kind::Request));
|
|
|
|
///
|
|
|
|
/// assert!(!launch_and_req.is_exactly(Kind::Launch));
|
|
|
|
/// assert!(!launch_and_req.is_exactly(Kind::Request));
|
|
|
|
/// assert!(!launch_and_req.is_exactly(Kind::Response));
|
|
|
|
/// assert!(!launch_and_req.is_exactly(Kind::Launch | Kind::Response));
|
|
|
|
/// ```
|
|
|
|
#[inline]
|
|
|
|
pub fn is_exactly(self, other: Kind) -> bool {
|
|
|
|
self.0 == other.0
|
|
|
|
}
|
2017-05-15 04:46:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl BitOr for Kind {
|
|
|
|
type Output = Self;
|
|
|
|
|
|
|
|
#[inline(always)]
|
|
|
|
fn bitor(self, rhs: Self) -> Self {
|
|
|
|
Kind(self.0 | rhs.0)
|
|
|
|
}
|
|
|
|
}
|