LINKUWANT COMMUNICATION ACTIONS
===============================

STATUS:
FUTURE ARCHITECTURE — NOT IMPLEMENTED


PURPOSE
-------

Administrator communications may eventually contain links allowing an
authorized administrator to quickly access a specific linkUwant record or
requested action.

Examples:

[view_submission_url]
[view_offer_url]
[view_domain_history_url]
[edit_submission_url]
[mark_junk_url]
[respond_url]


ABSOLUTE SECURITY RULE
----------------------

ALL protected administrator communication links require authenticated
administrator login.

Possession of a URL or token NEVER grants administrator authorization.


EXPECTED FUTURE FLOW
--------------------

1. Administrator clicks a link in an email.
2. Application receives an opaque action reference/token.
3. Application validates the reference.
4. Application checks for authenticated administrator session.
5. If not logged in:
       - Preserve the requested action/reference.
       - Redirect to administrator login.
6. Administrator logs in.
7. Application returns administrator to requested action.
8. Application verifies administrator permissions.
9. Application displays only the authorized information/action.
10. Destructive actions require confirmation.
11. Confirmed action is executed.
12. Action is logged.


ACTION REFERENCES
-----------------

Future URLs should expose as little internal information as practical.

Preferred conceptual form:

    /email_action.php?token=OPAQUE_RANDOM_VALUE

The token/reference itself does NOT authenticate the administrator.


FUTURE ACTION RECORD
--------------------

A future server-side action record may contain information such as:

- Action identifier
- User ID where applicable
- Domain ID where applicable
- Form/submission type
- Record ID
- Requested action
- Created date
- Expiration date
- Used date
- Status
- Administrator who executed the action
- IP/logging information


IMPORTANT
---------

Do NOT accept arbitrary table names or SQL instructions from a URL.

Future action names must map to specifically approved PHP application logic.

Examples:

VIEW_DOMAIN_HISTORY
VIEW_DOMAIN_OFFER
MARK_DOMAIN_OFFER_JUNK
EDIT_DOMAIN_OFFER
RESPOND_TO_DOMAIN_OFFER


DESTRUCTIVE ACTIONS
-------------------

A GET request should not silently perform a destructive database operation.

Preferred flow:

    Email link
        ->
    Login if required
        ->
    Show record/action
        ->
    Administrator confirms
        ->
    POST action
        ->
    Execute
        ->
    Log


DELETE / JUNK
-------------

Where practical, consider changing a record's status to junk/deleted rather
than permanently deleting it immediately.

Actual behavior will be decided when each form is implemented.


NOT PERMITTED
-------------

Communication links must never independently authorize sensitive actions such
as:

- Payment activity
- Password changes
- Credential changes
- Ownership transfers
- Broad account administration

Authentication and authorization are always required.