Try it yourself:

• Sign in to APEXCrafts: try password, face or Google sign-in.
• Create a free account: register with email or with your face, then verify with a code.

The myths and the reality

An APEX app has exactly one current authentication scheme, but other schemes in the same app can still be used, one session at a time.

The current scheme stays the default for everyone who opens the app normally. Any other scheme with Switch in Session enabled can take over for one visitor's session, when a link asks for it.

How it works

A link carrying the request APEX_AUTHENTICATION=<scheme name> tells APEX to use that scheme for this visit, provided the scheme has Switch in Session enabled.

1. The visitor opens your app and lands on the login page of the current scheme (your custom login).
2. They click Continue with Google. The button opens a protected page with the request APEX_AUTHENTICATION=GOOGLE.
3. APEX sees the request, switches this session to the scheme named GOOGLE, and sends the visitor to Google.
4. Google signs them in and returns to APEX, which runs the scheme's post-authentication procedure.
5. The visitor lands in the app. Everyone else keeps using the default login.

The link itself is plain, so a button or a menu entry can trigger it:

// "Continue with Google" button on the login page
apex.navigation.redirect(
  '/ords/f?p=' + apex.item('pFlowId').getValue() + ':1:' +
  apex.item('pInstance').getValue() + ':APEX_AUTHENTICATION=GOOGLE');

The scheme is found by its name, so give it a short, space-free name like GOOGLE.

Real example: APEXCrafts

APEXCrafts offers three sign-in methods, and every one of them ends on the same row in one table, APEXCRAFT_USERS.

Password and Google each use their own authentication scheme. Face sign-in reuses the custom scheme's session through post_login, and all three fill the same session items, so the rest of the app never cares how someone signed in.

Step-by-step setup

You need two schemes, both with Switch in Session enabled, and one post-authentication procedure that maps every sign-in to the same user row.

1. Keep your custom scheme as the current one

In Shared Components → Authentication Schemes, the custom scheme stays Current. Mine calls a PL/SQL function that checks the email and a salted, hashed password.

2. Store the Google keys in a Web Credential

Create an OAuth client in Google Cloud (type: Web application). Its redirect URI is the APEX callback, not one of your pages:

https:///ords/apex_authentication.callback

Then create a Web Credential in APEX with Authentication Type: OAuth2 Client Credentials, holding the Client ID and Client Secret.

3. Add the Google scheme next to it

Do not click Make Current Scheme on this one. If you do, your custom login stops being the default.

4. Map Google users to your own table

The post-authentication procedure reads what Google returned through APEX_JSON and decides who the person is. Three cases cover everyone:

l_sub   := apex_json.get_varchar2('sub');            -- Google's permanent user ID
l_email := lower(apex_json.get_varchar2('email'));

-- 1) seen this Google account before    -> sign in that member
-- 2) same mailbox as an existing member -> link Google to that member (no duplicate account)
-- 3) brand-new person                    -> create a MEMBER row, email already verified

Case 2 matters most. Without it, a member who first registered with a password would get a second account the first time they use Google.

5. Remember who is signed in, the same way for every method

Every scheme ends by calling one shared procedure that fills a few restricted application items (AI_USER_ID, AI_USERNAME, AI_USER_ROLE). Authorization schemes and pages then use those items, and never care which method was used to sign in.

Bonus: a third way in, without a third scheme

Face sign-in in APEXCrafts needs no scheme of its own: the server checks the face, then finishes the login with apex_authentication.post_login.

The browser turns the face into a 128-number signature (with the open-source face-api library), and the database compares it with the stored one using VECTOR_DISTANCE. A login can't be completed inside an AJAX call, so it takes two steps:

1. The check (AJAX). On a match, the server writes the member's email and a timestamp into two application items set to Restricted - May not be set from browser.
2. The sign-in (page submit). A process reads those items, accepts them only if they're under 60 seconds old, clears them, and signs the member in.

-- process "Face sign-in", runs only for request FACE_SIGNIN
l_email := :AI_FACE_EMAIL;
apex_util.set_session_state('AI_FACE_EMAIL', null);   -- one-time use
apex_util.set_session_state('AI_FACE_TIME',  null);
-- ... reject if missing or older than 60 seconds ...
apex_authentication.post_login(p_username => l_email);

Because only the server can write those items, a browser can't fake a face match. The same pattern works for any check you run yourself, such as a magic link or a one-time code.

Gotchas I hit, and the fixes

Security checklist

More ways in means more doors to lock, so check each of these before going live.

• One identity per person. Link methods by Google's sub first, then by email. Compare emails in a canonical form (lowercase, Gmail dots and +tags removed) so aliases can't create duplicate accounts.
• Never trust the browser. Identity proofs live in application items with Restricted - May not be set from browser, and expire quickly.
• Same rules for every method. Locked and inactive accounts are refused in the custom function and in every post-authentication procedure.
• Secrets stay in Web Credentials. API keys and client secrets never appear in code, and exports never include them.
• Roles come from your table. Authorization schemes read the role from the database on each page view, not from how the user signed in.
• Recovery leaks nothing it shouldn't**.** Recovery emails go only to real accounts, and codes are rate-limited per mailbox. If you show live "account found" checks, apply the same rule to sign-up and recovery, and decide that trade-off on purpose.

Wrap-up

One current scheme is APEX's default, not its limit: with Switch in Session, one app can offer password, Google and custom methods side by side.

The pattern is short to remember:

1. Keep your main login as the current scheme.
2. Add each extra method as its own scheme, with Switch in Session enabled.
3. Point a button at APEX_AUTHENTICATION=.
4. Send every scheme through post-authentication logic that maps people to one user table.

You can see the result live in APEXCrafts, the community app I'm building for Oracle APEX developers. If you try this pattern, or you've solved multi-method sign-in differently, tell me in the comments. I'd love to compare notes.

Try it yourself:

• Sign in to APEXCrafts: try password, face or Google sign-in.
• Create a free account: register with email or with your face, then verify with a code.

Thank You for your time.

If you need any help or have any questions, feel free to leave a comment or contact me via email.

arfaats22@gmail.com
support.apexcrafts@gmail.com

A chat assistant inside an Oracle APEX app. You ask questions like "Which projects are over budget?" and it answers only from your own project data.

How it works (simple version):

You ask a question
      ↓
APEX AI Agent picks the right Tool (a SQL query)
      ↓
Tool returns only the allowed data
      ↓
Cohere writes a short answer from that data

This is RAG (Retrieval-Augmented Generation): the AI does not guess from the internet. It reads the data your tools give it, and nothing else. That is how we limit the AI to our data.

Why this design is easy to maintain: there is no custom code to debug. Everything is APEX settings plus 5 small SQL queries.

2. What is free, and what are the limits

Be honest with yourself: a trial key is perfect for learning, demos, and a portfolio. For a real business app, you will need a paid Cohere key. The good news: you only change the key in one place (Step 3).

Tip: one question can use 2 or more calls (the agent picks a tool, then answers). Plan for roughly 300 to 400 questions a month.

3. Step 1: Create your free Oracle APEX workspace

1. Sign up at cloud.oracle.com (choose the Always Free option).
2. Create an APEX Service and select Always Free.
3. Save your ADMIN password safely.
4. Open APEX and create a workspace.

4. Step 2: Get your free Cohere API key

1. Sign up at dashboard.cohere.com.
2. Open API Keys and copy your Trial key.
   Security rule: never paste your key in a blog, screenshot, or GitHub. If it leaks, delete it in the Cohere dashboard and create a new one.

5. Step 3: Store the key safely (Web Credential)

In APEX go to Workspace Utilities → Web Credentials → Create and fill in:

Notes:

• Type the word Bearer, then one space, then your key.
• "Valid for URLs" makes sure the key is only ever sent to Cohere.
• Later, to move to a paid key, edit only this secret. Nothing else changes.

Click Create.

6. Step 4: Install the sample data

Go to App Builder → Gallery (or Sample Datasets) and install Project Data.

Why this dataset? It has real text and business meaning (projects, milestones, tasks, comments), which suits an AI assistant. It is small, so it will not use your storage.

It creates these tables and views:
EBA_PROJECTS, EBA_PROJECT_STATUS,
EBA_PROJECT_MILESTONES
EBA_PROJECT_TASKS
EBA_PROJECT_TASK_TODOS
EBA_PROJECT_TASK_LINKS
EBA_PROJECT_COMMENTS
Views: EBA_PROJECTS_V
EBA_PROJECTS_COMPLETED_V

7. Step 5: Connect APEX to Cohere (AI Service)

Go to Workspace Utilities → Generative AI → AI Services → Create.

Important: the Base URL domain (api.cohere.com) must match the "Valid for URLs" value from Step 3, or the call can be blocked.

Click Test Connection. When it succeeds, click Create.

8. Step 6: Create the 5 Tools (this is the data limit)

A Tool is a SQL query the AI is allowed to use. If data is not in a tool, the AI cannot see it.

For each tool, set Type = Retrieve Data.

Before you add each one, run its SQL in SQL Workshop. If it returns rows, it will work in the tool.

Tool 1: Projects

• Name: Projects
• Execution Point: Augment System Prompt (always loaded, because it is small and almost every question needs it)
• Description: List of all projects with status, lead, budget, cost, remaining budget, over-budget flag, task progress, milestone count, comment count and completion date. Use for any question about projects, budgets or costs.

select 'PROJECT: ' || p.name
    || ' | Status: '      || nvl(s.description, 'Unknown')
    || ' | Lead: '        || nvl(p.project_lead, 'Not set')
    || ' | Budget: '      || nvl(p.budget, 0)
    || ' | Cost: '        || nvl(t.cost, 0)
    || ' | Remaining: '   || (nvl(p.budget, 0) - nvl(t.cost, 0))
    || case when nvl(p.budget, 0) - nvl(t.cost, 0) < 0 then ' (OVER BUDGET)' end
    || ' | Tasks done: '  || nvl(t.done, 0) || ' of ' || nvl(t.total, 0)
    || ' | Milestones: '  || (select count(*) from eba_project_milestones m where m.project_id = p.id)
    || ' | Comments: '    || (select count(*) from eba_project_comments c where c.project_id = p.id)
    || ' | Completed on: '|| nvl(to_char(p.completed_date, 'DD-MON-YYYY'), '-')
    || ' | Today: '       || to_char(sysdate, 'DD-MON-YYYY') as info
  from eba_projects p
  left join eba_project_status s on s.id = p.status_id
  left join (select project_id,
                    sum(cost) cost,
                    count(*)  total,
                    count(case when nvl(is_complete_yn,'N') = 'Y' then 1 end) done
               from eba_project_tasks
              group by project_id) t
         on t.project_id = p.id
 order by p.name

Tool 2: Milestones

• Name: Milestones
• Execution Point: On Demand
• Description: All milestones with their project, due date, task progress and status (ACHIEVED, OVERDUE, IN PROGRESS, NO TASKS). Use for questions about milestones, deadlines, due dates or what has been achieved.

select 'MILESTONE: ' || m.name
    || ' | Project: '    || p.name
    || ' | Due: '        || to_char(m.due_date, 'DD-MON-YYYY')
    || ' | Tasks done: ' || nvl(x.done, 0) || ' of ' || nvl(x.total, 0)
    || ' | Status: ' ||
       case when nvl(x.total, 0) = 0             then 'NO TASKS'
            when x.done = x.total                then 'ACHIEVED'
            when m.due_date < trunc(sysdate)     then 'OVERDUE'
            else 'IN PROGRESS' end as info
  from eba_project_milestones m
  join eba_projects p on p.id = m.project_id
  left join (select milestone_id,
                    count(*) total,
                    count(case when nvl(is_complete_yn,'N') = 'Y' then 1 end) done
               from eba_project_tasks
              where milestone_id is not null
              group by milestone_id) x
         on x.milestone_id = m.id
 order by m.due_date

Tool 3: Tasks

• Name: Tasks
• Execution Point: On Demand
• Description: All tasks with project, milestone, assignee, start and end dates, cost and status (DONE, OVERDUE, OPEN). Use for questions about tasks, assignees, workload, overdue or late work.

select 'TASK: ' || t.name
    || ' | Project: '   || p.name
    || ' | Milestone: ' || nvl(m.name, '-')
    || ' | Assignee: '  || nvl(t.assignee, 'Unassigned')
    || ' | Start: '     || to_char(t.start_date, 'DD-MON-YYYY')
    || ' | End: '       || to_char(t.end_date, 'DD-MON-YYYY')
    || ' | Cost: '      || nvl(t.cost, 0)
    || ' | Status: ' ||
       case when nvl(t.is_complete_yn,'N') = 'Y' then 'DONE'
            when t.end_date < trunc(sysdate)     then 'OVERDUE'
            else 'OPEN' end as info
  from eba_project_tasks t
  join eba_projects p on p.id = t.project_id
  left join eba_project_milestones m on m.id = t.milestone_id
 order by p.name, t.end_date

Tool 4: To-Dos

• Name: Task_ToDos
• Execution Point: On Demand

Description: Checklist to-do items inside tasks, with their task, project, assignee and status (DONE or OPEN). Use for questions about to-dos, checklist items or small pending actions.

select 'TO-DO: ' || d.name
    || ' | Task: '     || t.name
    || ' | Project: '  || p.name
    || ' | Assignee: ' || nvl(d.assignee, 'Unassigned')
    || ' | Status: '   || case when nvl(d.is_complete_yn,'N') = 'Y'
                               then 'DONE' else 'OPEN' end as info
  from eba_project_task_todos d
  join eba_project_tasks t on t.id = d.task_id
  join eba_projects p      on p.id = d.project_id
 order by p.name, t.name

Tool 5: Comments

• Name: Comments
• Execution Point: On Demand
• Description: Comments written on projects, with project name, author and date (latest 10 per project). Comments belong to projects, not milestones or tasks. Use for questions about comments, updates, notes, issues or what people said.

select 'COMMENT on project ' || project_name
    || ' | By: '   || created_by
    || ' | Date: ' || to_char(created, 'DD-MON-YYYY')
    || ' | Text: ' || substr(comment_text, 1, 500) as info
  from (select p.name as project_name, c.created, c.created_by, c.comment_text,
               row_number() over (partition by c.project_id
                                  order by c.created desc) rn
          from eba_project_comments c
          join eba_projects p on p.id = c.project_id)
 where rn <= 10
 order by project_name, created desc

Why "Execution Point" matters:

• Augment System Prompt = sent with every question (use only for small, always-needed data).
• On Demand = the AI calls the tool only when the question needs it. This saves tokens and keeps answers focused.

Why the Description matters: the AI reads the description to decide which tool to call. Write it clearly, and say what the tool is for.

9. Step 7: Create the AI Agent

Go to Generative AI → AI Agents → Create.

1. Select the AI Service Cohere AI.
2. Attach all 5 tools.
3. Paste this System Prompt:

You are a project assistant. Answer ONLY from the data returned by your tools.
Every record includes "Project: <name>". Use the project name to connect data
from different tools (for example, milestones and comments of the same project).
Comments belong to projects, not to milestones or tasks.
If the answer is not in the data, say "I couldn't find that in the project data."
Keep answers short. Use a small table when listing more than 3 items.

Paste this Welcome Message:

Hi! 👋 I'm your Project Assistant. Ask me about projects, tasks, milestones, or comments, and I'll answer from the project data.

Why this prompt works:

• "Answer ONLY from the data" is the data limit.
• The fixed fallback sentence makes refusals predictable.
• "Keep answers short" saves tokens and reads better.

(Menu names can differ slightly between APEX versions. Follow the closest option.)

10. Step 8: Add the Ask AI button to a page

1. Create Page → Blank Page, name it AI Assistant.
2. In Page Designer, right-click a region → Create Button:

3. Right-click the button → Create Dynamic Action:

4. Click Save and Run, then press Ask AI.

11. Step 9: Test it

Use these questions. Do not run them all every day, because each one uses your free Cohere calls.

Projects

• Which projects are over budget?
• Show me all in-progress projects
• What is the total budget and total cost?
• Which project has the most budget remaining?

Milestones

• Which milestones are achieved?
• Which milestones are overdue?
• What milestones are due this month?

Tasks

• Show me all overdue tasks
• Who has the most open tasks?
• Which tasks are unassigned?

To-Dos

• What to-dos are still open?

Comments

• Summarize the latest comments
• Which projects have issues mentioned in comments?

Mixed (several tools at once)

• Which achieved milestones have comments on their project?
• Give me a quick health summary of all projects
• Which over-budget projects also have overdue tasks?

Scope test (must refuse):

• Who is the Prime Minister of India?

Expected reply: "I couldn't find that in the project data."

Quality tip: keep a simple table of question, expected answer, and pass or fail. Re-run a few of them after every change.

12. Troubleshooting

Introduction

Oracle APEX applications often require payment functionality for bookings, registrations, subscriptions, and event management systems. While Razorpay provides an excellent checkout experience, one challenge quickly appears:

Razorpay Order APIs require the Secret Key, and exposing secret keys directly in Oracle APEX JavaScript is insecure.

The solution is simple:

• Oracle APEX handles the frontend.

• A small Node.js backend securely creates Razorpay orders.

• Render hosts the backend for free.

• GitHub stores and manages the backend code.

This guide walks through the complete process from local development to deployment and integration with Oracle APEX.

Architecture Overview

The payment flow looks like this:

Oracle APEX
     |
     | Request order creation
     ↓
Node.js Backend (Render)
     |
     | Uses Razorpay Secret Key
     ↓
Razorpay Orders API
     |
     | Returns order_id
     ↓
Oracle APEX
     |
     | Opens Razorpay Checkout
     ↓
Customer Payment

The important principle is:

Secret keys never leave the backend.

Step 1: Install Node.js

Download and install the LTS version of Node.js:

https://nodejs.org

Verify installation:

node -v
npm -v

Example output:

v24.11.0
11.6.2

Step 2: Create Project Folder

Create a folder for the backend.

mkdir razorpay-backend
cd razorpay-backend

Step 3: Initialize Node Project

Create a package.json file:

npm init -y

Step 4: Install Required Packages

Install the dependencies:

npm install express cors axios

Installed packages:

• Express → Web server

• CORS → Allows Oracle APEX to call the backend

• Axios → Calls Razorpay APIs

Step 5: Create index.js

Create a file named: index.js

Paste the following code:

const express = require('express'); const cors = require('cors'); const axios = require('axios');

const app = express();

app.use(cors()); app.use(express.json());

const RZP_KEY_ID = 'YOUR_TEST_KEY_ID'; const RZP_KEY_SECRET = 'YOUR_TEST_SECRET';

app.get('/', (req, res) => { res.send('Razorpay backend up'); });

app.post('/create-order', async (req, res) => { try {
const amountRupees = Number(req.body.amount) || 0;
const bookingRef = req.body.booking_ref || 'NO_REF';

const amountPaise = Math.round(amountRupees * 100);

const auth = Buffer.from(
  RZP_KEY_ID + ':' + RZP_KEY_SECRET
).toString('base64');

const response = await axios.post(
  'https://api.razorpay.com/v1/orders',
  {
    amount: amountPaise,
    currency: 'INR',
    receipt: bookingRef
  },
  {
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Basic ' + auth
    }
  }
);

res.json({
  success: true,
  order_id: response.data.id,
  amount: response.data.amount,
  currency: response.data.currency
});
} catch(err) {
res.status(500).json({
  success: false,
  error: err.message
});
}});
const PORT = process.env.PORT || 3000;

app.listen(PORT, () => { console.log('Server listening on port', PORT); });

Step 6: Run the Backend Locally

Start the server:

node index.js

Expected output:

Server listening on port 3000

Open:

http://localhost:3000

Expected result:

Razorpay backend up

Step 7: Create GitHub Repository

Create a repository:

razorpay-backend

Initialize Git:

git init
git add .
git commit -m "Initial Razorpay backend"

Connect GitHub:

git branch -M main
git remote add origin https://github.com/your-username/razorpay-backend.git
git push -u origin main

Step 8: Deploy on Render

Visit:

https://render.com

Login using GitHub.

Create:

New → Web Service

Select:

razorpay-backend

Configure:

Deploy the service.

Render provides a URL similar to:

https://razorpay-backend-xxxx.onrender.com

Step 9: Test Deployment

Open:

https://razorpay-backend-xxxx.onrender.com

Expected output:

Razorpay backend up

Step 10: Test Order Creation API

Example request:

curl -X POST https://your-backend.onrender.com/create-order -H "Content-Type: application/json" -d "{"amount":1000,"booking_ref":"BOOK_001"}"

Expected response:

{ "success": true, "order_id": "order_Q123456789", "amount": 100000, "currency": "INR" }

Step 11: Add Razorpay Checkout to Oracle APEX

Page Attributes → JavaScript File URLs:

https://checkout.razorpay.com/v1/checkout.js

Step 12: Create Order From Oracle APEX

Example JavaScript:

fetch( 'https://your-backend.onrender.com/create-order', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ amount: 1000, booking_ref: 'BOOK001' }) } ) .then(res => res.json()) .then(data => { var options = { key: 'YOUR_KEY_ID', amount: data.amount, currency: 'INR', order_id: data.order_id }; new Razorpay(options).open(); });

Step 13: Test Using Razorpay Test Cards

Use Razorpay test credentials:

Card Number: 4111 1111 1111 1111
Expiry Date: Any future date
CVV: 123
OTP: 123456

Security Considerations

Never expose:

• Razorpay Secret Key

• Webhook Secret

• API Credentials

Only the backend should access these values.

Final Result

By the end of this implementation you have:

• Oracle APEX frontend

• Secure Node.js backend

• Free cloud deployment

• Real Razorpay order creation

• Test payments working end-to-end

This architecture scales well from prototypes to production systems and follows standard payment security practices.

Thank You for your time.

If you need any help or have any questions, feel free to leave a comment or contact me via email.

Email: arfaats999@gmail.com

1.1 Technology Stack

1.2 How It Works — Flow Summary

• User opens the APEX login page (Page 9999)
• Two buttons are visible: Register Your Face and Login with Face Detection
• Registration: user enters username → camera opens → face is auto-captured after 5 confirmed frames → 128-point descriptor saved to DB
• Login: camera opens → face scanned → descriptor compared against DB via Euclidean distance → if match ≤ 0.5 threshold → login submitted automatically
• APEX custom auth scheme validates the bypass password and confirms username exists in apex_face_users

2. Database Setup

2.1 Face Users Table

Run this SQL in SQL Workshop → SQL Commands:

CREATE TABLE apex_face_users (
id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
username  VARCHAR2(100) NOT NULL,
face_descriptor  CLOB NOT NULL,
created_date     DATE DEFAULT SYSDATE
);

NOTE: face_descriptor stores a 128-element JSON float array like [0.12, -0.34, 0.56, ...]. It is NOT an image — do not use a file upload control to populate it.

2.2 Custom Authentication Function

Run this in SQL Workshop → SQL Commands:

CREATE OR REPLACE FUNCTION custom_face_auth ( p_username IN VARCHAR2, p_password IN VARCHAR2 ) RETURN BOOLEAN IS l_count NUMBER; BEGIN IF p_password = 'FACE_BYPASS_2024' THEN SELECT COUNT(*) INTO l_count FROM apex_face_users WHERE UPPER(username) = UPPER(p_username); RETURN l_count > 0; END IF; RETURN FALSE; END;

3. APEX Authentication Scheme

Go to: Shared Components → Authentication Schemes → Create → From Scratch

4. Model Files Setup

4.1 Download from GitHub

Download all 6 files from: https://github.com/justadudewhohacks/face-api.js/tree/master/weights

● tiny_face_detector_model-shard1
● tiny_face_detector_model-weights_manifest.json
● face_landmark_68_model-shard1
● face_landmark_68_model-weights_manifest.json
● face_recognition_model-shard1
● face_recognition_model-shard2 ← critical, often missed
● face_recognition_model-weights_manifest.json

4.2 Upload to APEX

Go to: Shared Components → Static Application Files → Upload

● Create a folder called models/
● Upload all 7 files into the models/ folder
● Reference path: #APP_FILES#models/

IMPORTANT: face_recognition_model has TWO shards (shard1 and shard2). Missing shard2 causes a tensor shape error and models will not load.

5. APEX Page 9999 Setup

5.1 Existing Items (Pre-built by APEX)

5.2 New Buttons to Create

5.3 Dynamic Actions

For each button create a Dynamic Action:

●        Event: Click
●        Selection Type: Button → select the button
●        TRUE Action: Execute JavaScript Code
○        Login button → Code: openFaceDetection()
○        Register button → Code: openRegisterModal()
Fire on Page Load: NO

5.4 HTML Regions to Create

6. AJAX Callback Processes

Go to: Page 9999 → Processing → right-click → Create Process → AJAX Callback

6.1 REGISTER_FACE - Saves a new face descriptor or updates existing one:

DECLARE l_username VARCHAR2(100) := apex_application.g_x01; l_descriptor CLOB := apex_application.g_x02; l_count NUMBER; BEGIN SELECT COUNT(*) INTO l_count FROM apex_face_users WHERE username = l_username; IF l_count > 0 THEN UPDATE apex_face_users SET face_descriptor = l_descriptor, created_date = SYSDATE WHERE username = l_username; ELSE INSERT INTO apex_face_users (username, face_descriptor) VALUES (l_username, l_descriptor); END IF; COMMIT; htp.p('{"status":"success","username":"' || l_username || '"}' ); EXCEPTION WHEN OTHERS THEN htp.p('{"status":"error","message":"' || SQLERRM || '"}' ); END;

6.2 VERIFY_FACE Returns all stored face descriptors for JS-side Euclidean comparison:

DECLARE l_json CLOB := '['; l_first BOOLEAN := TRUE; BEGIN FOR r IN (SELECT username, face_descriptor FROM apex_face_users) LOOP IF NOT l_first THEN l_json := l_json || ','; END IF; l_json := l_json || '{"username":"' || r.username || '","descriptor":' || r.face_descriptor || '}'; l_first := FALSE; END LOOP; l_json := l_json || ']'; apex_util.set_session_state('P9999_STATUS', l_json); htp.p(l_json); END;

6.3 DO_FACE_LOGIN Sets session state before page submit:

BEGIN apex_util.set_session_state('P9999_USERNAME', apex_application.g_x01); htp.p('{"status":"ok"}'); END;

7. JavaScript — Execute when Page Loads

Paste the entire block below into: Page 9999 → JavaScript → Execute when Page Loads

7.1 Model Loading

const MODEL_URL = 'https://oracleapex.com/ords/r/unionsys/face-detection/files/static/v1/models'; let cameraStream = null, detectionInterval = null, modelsLoaded = false; const faceScript = document.createElement('script'); faceScript.src = 'https://cdn.jsdelivr.net/npm/face-api.js@0.22.2/dist/face-api.min.js'; faceScript.onload = async function () { await faceapi.nets.tinyFaceDetector.loadFromUri(MODEL_URL); await faceapi.nets.faceLandmark68Net.loadFromUri(MODEL_URL); await faceapi.nets.faceRecognitionNet.loadFromUri(MODEL_URL); modelsLoaded = true; console.log('Face models loaded.'); }; document.head.appendChild(faceScript);

7.2 Key Fix — Landmark Accuracy The most important fix for accurate face landmark rendering (eyes, lips, nose in correct position): // After video loads, match canvas dimensions to display size

var displaySize = { width: video.offsetWidth, height: video.offsetHeight }; faceapi.matchDimensions(canvas, displaySize);

// Before drawing detections, results to display size //

var resized = faceapi.resizeResults(det, displaySize); faceapi.draw.drawDetections(canvas, resized); faceapi.draw.drawFaceLandmarks(canvas, resized);

7.3 Login Flow On successful face match, the JS sets the APEX items and submits the login:

apex.item('P9999_USERNAME').setValue(username); apex.item('P9999_PASSWORD').setValue('FACE_BYPASS_2024'); apex.page.submit({ request: 'LOGIN' }); The custom_face_auth function then checks apex_face_users and returns TRUE if username exists.

8. Bugs Fixed Along the Way

9. Complete End-to-End Flow

9.1 Registration Flow

●        User clicks Register Your Face button
●        openRegisterModal() fires via Dynamic Action
●        Modal opens — Step 1 shown: username input + Continue button
●        User enters username and clicks Continue
●        startRegisterCamera() fires — webcam starts
●        Step 2 shown: ring with live video feed
●        faceapi detects face every 200ms using TinyFaceDetector
●        faceapi.matchDimensions ensures landmarks render accurately
●        5 confirmed frames fill the progress dots
●        AUTO CAPTURE fires — no button click needed
●        Ring turns green with pulsing glow
●        REGISTER_FACE AJAX process called with username (x01) + descriptor JSON (x02)
●        PL/SQL inserts or updates apex_face_users table
●        Success message shown, modal closes after 2 seconds

9.2 Login Flow

● User clicks Login with Face Detection button
● openFaceDetection() fires via Dynamic Action
● Verification overlay opens with violet/indigo pulsing ring
● Webcam starts, faceapi runs every 200ms
● 5 confirmed frames fill progress dots (amber color)
● VERIFY_FACE AJAX called — PL/SQL returns all stored descriptors as JSON
● JS loops through stored descriptors and calculates Euclidean distance
● Best match checked against threshold 0.5
● Match found → ring turns green → Welcome message shown
● After 1.8s: P9999_USERNAME = matched username, P9999_PASSWORD = FACE_BYPASS_2024, page submitted
● custom_face_auth function runs → checks apex_face_users → returns TRUE → user logged in
● APEX redirects to home page
● No match → ring turns red → Access Denied → overlay closes after 3 seconds

10. Troubleshooting Quick Reference

11. Security Notes

The FACE_BYPASS_2024 password is a shared secret used to bypass normal password auth. For production use, consider rotating this value and storing it in APEX Application Settings rather than hardcoding in JS.

● Face descriptors are stored as plain JSON in CLOB — consider encrypting at rest for production
● Euclidean threshold of 0.5 balances accuracy vs security — lower = stricter
● For multi-user environments, register multiple face angles per user for better accuracy
● HTTPS is required for webcam access in all modern browsers
● This implementation is suitable for internal tools and demos — for banking/high security apps, use a dedicated biometric SDK

Thank You for your time.

If you need any help or have any questions, feel free to leave a comment or contact me via email.

Email: arfaats999@gmail.com