3. — Scott Spendolini
— scott.spendolini@enkitec.com
— @sspendol
— Ex-Oracle Employee of 10 years
— Senior Product Manager for Oracle APEX
from 2002 through 2005
— Founded Sumner Technologies
in October 2005
— Co-Founded Sumneva in January 2010
— Joined Enkitec in June 2012
— Oracle Ace Director
— Author, Expert Oracle Application Express Security
— Co-Author, Pro Oracle Application Express
— “Scott” on OTN Forums
About the Presenter
3
4. About Enkitec
— Oracle Platinum Partner
— Established in 2004
— Headquartered in Dallas, TX
— Locations throughout the US & EMEA
— Specialties include
— Exadata Implementations
— Development Services
— PL/SQL / Java / APEX
— DBA/Data Warehouse/RAC
— Business Intelligence
4
7. Overview
7
— APEX is an amazing development environment
— Few others are as fast & as robust
— But, do you really know what happens once you
click submit?
8. — APEX is not magic
— There’s a method to everything that goes on
— Most of which is more basic
than you may think
— We’ll dispel some of the
“magic” today, so that
you truly understand
how this amazing
technology works
Behind the Curtain
8
9. KISS: Keep It Simple, Stupid!
— For this session, we’re going to focus on the
internals of APEX, not the complexity of the
application
— This, our example will be extremely simple
— 2 Pages
— Login Page
— Blank Page
9
13. Terminology
13
— Much of APEX’s internal APIs and variables still
use the older names
— Most of which is based on
Oracle Flows terminology
— Subsequent versions of APEX
include APIs & variables that start
with the APEX_ prefix
— Thus, to understand the internals
of APEX, you need to be able
to map legacy term to
modern ones
14. Terminology
14
Legacy Name Modern Name
Company Workspace
Flow Application
Step Page
Plug Region
Instance Session
Request Request
Debug Debug
16. HTML Form Basics
16
— HTML Forms are used to pass data to a server
— Used by all web pages on the internet
— Regardless of the underlying technology
— Forms contain items which are passed as
parameters to the form action
— Text Field
— Radio Group
— Select List
— And so on...
17. — Each HTML Form has to have a form tag and a
way to submit it
— Can optionally have input tags; most have several
— The form tag will have the following attributes:
— Name
— Action
— Method
— ID
HTML Form Basics
17
18. HTML Form Basics
— All HTML forms start like this:
18
<form action="form_action.asp" method="post"
name="my_form" id="myForm">
Procedure
Name
HTTP
Method
Form Name Form ID
19. Get vs. Post
19
— All HTTP & HTTPS transactions for every web site
ever fall into one of two categories:
— GET
— POST
20. Get
— Typically involves passing parameters over the URL to a
procedure
— More “usable” than POST
— Can be:
— Bookmarked
— Cached
— Remain in browser history
— Distributed & shared
— Hacked
— In APEX-speak, this is also known as Page Rendering
and handled by wwv_flow.show
20
21. Post
— When a web page “sends” form data to the server
directly
— Using the attributes of the form to determine which
server process to execute
— Item names will also map to the form process’s input
parameters
— Typically used to change or update data on the
server
— Thus, POST requests are never cached
— In APEX-speak, this is also known as Page
Processing and handled by wwv_flow.accept
21
24. wwv_flow
24
— wwv_flow is essentially APEX
— Contains many global variables, as well as
several functions & procedures
— Some of which you can use, other which are internal only
— We’ll focus on just a couple of them:
— accept
— show
25. Basic HTML Form
25
<form action="form_action.asp" method="post"
name="my_form" id="myForm">
Procedure
Name
HTTP
Method
Form Name Form ID
26. APEX HTML Form
26
<form action="wwv_flow.accept" method="post"
name="wwv_flow" id="wwvFlowForm">
Procedure
Name
HTTP
Method
Form Name Form ID
27. wwv_flow.accept
— PL/SQL package.procedure that APEX calls when
POSTing pages
— Called for every APEX page that’s submitted
— Contains a number of parameters which are populated
based on a combination of system-defined variables and
what the user enters into the form items
27
28. APEX_040200 Schema
— A lot can be learned about the internals of APEX
by browsing the APEX_040200 schema
— However, NEVER, EVER, EVER make any changes to
anything here!
— If you want to explore this schema,
its best done on an isolated,
private instance of APEX
— Oracle XE
— VMWare/Virtual Box/etc.
28
30. The f Procedure
30
— Let’s start by navigating to our URL:
— http://vm/apex/f?p=134:1
31. The f Procedure
— The string 134:1 is passed to the p parameter of
the f procedure
31
PROCEDURE f
Argument Name Type In/Out Default?
------------------ --------- ------ ---------------
P VARCHAR2! IN DEFAULT
P_SEP VARCHAR2! IN DEFAULT
P_TRACE VARCHAR2! IN DEFAULT
C VARCHAR2! IN DEFAULT
PG_MIN_ROW! VARCHAR2! IN DEFAULT
PG_MAX_ROWS! VARCHAR2! IN DEFAULT
PG_ROWS_FETCHED! VARCHAR2! IN DEFAULT
FSP_REGION_ID! VARCHAR2! IN DEFAULT
SUCCESS_MSG! VARCHAR2! IN DEFAULT
NOTIFICATION_MSG! VARCHAR2! IN DEFAULT
CS VARCHAR2! IN DEFAULT
S VARCHAR2! IN DEFAULT
TZ VARCHAR2! IN DEFAULT
P_LANG VARCHAR2! IN DEFAULT
P_TERRITORY VARCHAR2! IN DEFAULT
134:1
32. The f Procedure
— The f procedure will then tokenize the p
parameter into its component parts and call the
wwv_flow.show procedure
32
PROCEDURE SHOW
Argument Name! Type! ! ! In/Out Default?
--------------------------------------------------------------
P_REQUEST VARCHAR2 IN DEFAULT
P_INSTANCE VARCHAR2 IN DEFAULT
P_FLOW_ID VARCHAR2 IN DEFAULT
P_FLOW_STEP_ID VARCHAR2 IN DEFAULT
P_DEBUG VARCHAR2 IN DEFAULT
P_ARG_NAMES TABLE OF VARCHAR2(32767) IN DEFAULT
P_ARG_VALUES TABLE OF VARCHAR2(32767) IN DEFAULT
P_CLEAR_CACHE TABLE OF VARCHAR2(32767) IN DEFAULT
P_BOX_BORDER VARCHAR2 IN DEFAULT
P_PRINTER_FRIENDLY VARCHAR2 IN DEFAULT
P_TRACE VARCHAR2 IN DEFAULT
P_COMPANY NUMBER IN DEFAULT
P_MD5_CHECKSUM VARCHAR2 IN DEFAULT
P_LAST_BUTTON_PRESSED VARCHAR2 IN DEFAULT
P_ARG_NAME VARCHAR2 IN DEFAULT
P_ARG_VALUE VARCHAR2 IN DEFAULT
134
1
34. wwv_flow.show
34
— Procedure that handles all APEX page rendering
or GETs
— Called most often by the f?p procedure in the
URL
— Also used in Ajax transactions
— The f procedure will decompose p= to its
component parameters and then call
wwv_flow.show
37. wwv_flow.show Parameters
— p_arg_names
— p_arg_name used when passing a single item
— p_arg_values
— p_arg_value used when passing a single value
— p_printer_friendly
— Printer Friendly mode
— “YES” to enable; “NO” or NULL to disable
37
38. wwv_flow.show Parameters
— p_trace
— When passed “YES”, APEX will generate a SQL trace file
based on the current page view
— Done in the background so that it does not slow down processing
— A SQL trace file will be generated in $ORACLE_BASE/
admin/SID/udump
— The SQL trace file can then be analyzed with TKPROF,
Profiler, SQL Developer or any number of other tools
— Note: You will need filesystem access to get to the trace
file; thus you may need to seek help from your DBA/
system admin
38
42. Page Rendering
— APEX will render a page
first by display/render
position
— Multiple components within the
same display/render position
can be sequenced accordingly
— At any point, any component
can be conditional and may
or may not render
42
44. NLS Parameters
— National Language Settings (NLS) parameters
must be set for each and every page view
— Seems inefficient, but there is no way to guarantee that
an APEX session will be linked to the same database
session from page view to page view
— Thus, we need to set these each and every time
44
45. NLS Parameters
— Some NLS settings can be managed from within
an APEX application
— Shared Components > Globalization
— All can be set from the value of an APEX item
— Allowing for
flexibility
between users of
the same
application
45
46. NLS Parameters
— Built-in NLS settings will show up in the APEX
Debug mode report at the very top of the report
— If needed, you can also manually set additional
NLS Parameters
46
49. Session management
— After NLS Parameters are set, APEX checks to see
if you are logged in or not
— APEX will also check to see if you are also logged in a
developer in the same workspace as the application
which you are running
— If so, then you will also see the developer’s toolbar:
49
50. — Debug log of an unauthenticated session vs. an
authenticated session
Session management
50
Unauthenticated Session
Authenticated Session
51. Session management
51
— By default, this functionality is built in to APEX
and does not need to be enabled
— You can override APEX’s session management, but you
better know what you are doing!
— If you choose to implement your own Page Session
Management, it is controlled via either the Page
Sentry Function or Session Verify Function in
the Authorization Scheme
52. Session management
— When a session is not valid, APEX will redirect to
one of three places:
— Login Page
— Built In Login Page
— URL
52
53. D E M O N S T R A T I O N
SESSION NOT VALID
53
54. Page Sentry & Session Verify
54
— APEX provides the ability to take over session
management entirely
— Page Sentry Function
— Executed before EVERY APEX page view
— Can check any criteria to determine if the session is valid
— Session Verify Function
— Determines whether or not a valid session exists
— Can only use one of these, not both
58. Authentication Scheme
— What happens next depends on whether the user
is authenticated or not
58
Authenticated:
Continue to Display Page Requested
Unauthenticated:
Redirect to Login Page defined in the
Authentication Scheme
59. Authentication Scheme
— Since we are not yet authenticated, APEX will
redirect to the Login Page
— Which will run through the Page Rendering phase
— NLS Parameters
— Page Session Management
— Which will pass this time, as the Login Page will display to an
unauthenticated user
— Computations
— Processes
— Regions
59
61. Get Username Cookie Process
— Process that will check to see if there is an APEX
username stored in the APEX session cookie
— If so, it will set the default value of P101_USERNAME to
this value
61
:P101_USERNAME :=
apex_authentication.get_login_username_cookie;
66. Page Processing
— APEX will process a page first by
process position
— Multiple components within the same
display/render position can be sequenced
accordingly
— At any point, any component can be
conditional and may or may not render
66
67. Page Processing
— Let’s enter our username & password and click
Login to start processing our page
67
68. Page Processing
— When the Login button is clicked, APEX will POST
a transaction to the server
— We can use Web Developer to see the
parameters it will pass to wwv_flow.accept
68
72. wwv_flow.accept Parameters
— p_request
— Typically set by the button clicked on a POST
— Can be passed via the URL in a GET
— But it will only be good for the next page phase
— Can not get the value of p_request in Page Rendering if
the page is submitted/POSTed
72
73. wwv_flow.accept Parameters
— p_instance
— Session ID
— Also referred to as :APP_SESSION or :SESSION_ID
— Automatically maintained by APEX
— Can not alter programmatically
73
74. wwv_flow.accept Parameters
— p_flow_id
— Application ID
— Also referred to as :APP_ID
— Automatically set by APEX based on which application
you’re running
— Can not alter programmatically
74
75. wwv_flow.accept Parameters
— p_company
— Workspace ID
— Also referred to as :WORKSPACE_ID
— Not typically present in the HTML rendered by APEX
— But is calculated inside the wwv_flow.accept procedure
— Can not alter programmatically
75
78. wwv_flow.accept Parameters
— p_arg_values
— Used to protect hidden items from being manipulated via
JavaScript
— When a hidden & protected item is rendered, there will
be a corresponding p_arg_values item rendered as well
78
<input type="hidden" id="P2_EMPNO" name="p_t01" value="7369" />
<input type="hidden" name="p_arg_values" value="9DDE9C18F8337D..." />
79. wwv_flow.accept Parameters
— p_t01 ... p_t200
— Set of VARCHAR parameters used to receive APEX page
item values
— This is where the “200 item per page” limit comes from
— Which is not accurate, since it’s really 200 enabled items per page
79
<input type="text" id="P1_ITEM" name="p_t01" value="" size="30"
maxlength="4000" class="text_field" />
APEX Item
Parameter
Item
80. wwv_flow.accept Parameters
— p_v01 ... p_v200
— Set of 200 arrays used to store results from items that
return potentially more than one value
— Multi-select Lists, Shuttle Regions, etc.
80
<select name="p_v01" id="P1_ITEM" size="1" multiple="multiple"
class="multi_selectlist">
Array Item APEX Item
81. wwv_flow.accept Parameters
— f01 ... f50
— Group of 50 arrays, typically used in conjunction with
g_f01 ... g_f50
— Most often used with tabular forms & APEX_ITEM API calls
— Name used for PL/SQL; ID used for JavaScript
81
<input type="text" name="f03" size="12" value="" id="f03_0001" />
<input type="text" name="f03" size="12" value="" id="f03_0002" />
<input type="text" name="f03" size="12" value="" id="f03_0003" />
Array Name Array
Element ID
82. wwv_flow.accept Parameters
— x01 ... x20
— Group of 20 VARCHARs, typically used in conjunction with
the global variables g_x01 ... g_x10
— Difference between the parameter count & global variable count can
be attributed to APEX itself needing extras
— Most often used with Ajax transactions to pass
parameters
82
84. wwv_flow.accept Parameters
— p_trace
— When passed “YES”, APEX will generate a SQL trace file
based on the current page view
— Done in the background so that it does not slow down processing
— A SQL trace file will be generated in $ORACLE_BASE/
admin/SID/udump
— The SQL trace file can then be analyzed with TKPROF,
Profiler, SQL Developer or any number of other tools
— Note: You will need filesystem access to get to the trace
file; thus you may need to seek help from your DBA/
system admin
84
86. Items
86
— APEX Page Items are named p_t01 through
p_t200
— The PX_ITEM_NAME is never directly sent back to the
database
— Used for client-side JavaScript interactions
— Thus, if all APEX pages items are named the
same, then how does it map them to the
corresponding page item in an application when
submitting a page?
88. Item Mapping
— p_arg_names values will map back to the
internal item ID in the wwv_flow_step_items
table:
88
89. Item Mapping
— The ID of an input element does not get
submitted back to the server
— Thus, the need for the p_arg_names array
— It provides the mapping from the p_txx elements
to the corresponding APEX page items
89
Parameter
p_t01
p_t02
ID p_arg_name Item Name
1 8295929934913911 P101_USERNAME
2 8296003745913912 P101_PASSWORD
92. Validations, Computations & Processes
92
— After validating that the session is still valid,
APEX will process all Validations, Computations
& Processes according to their execution point
and corresponding sequence
— Nothing in this phase will ever be output to the screen
— All “Built In” APEX Processes are merely calls to
underlying PL/SQL procedures
— Application Builder abstracts this concept to keep things simple
93. Set Username Cookie
— Sets the LOGIN_USERNAME_COOKIE based on the
value of the username entered
— Regardless of whether it successfully authenticated or not
— Can be disabled for security purposes
93
apex_authentication.send_login_username_cookie
(
p_username => lower(:P101_USERNAME)
);
94. Login
— APEX API Call to the standard login procedure:
apex_authentication.login
— Will use the current authentication scheme and
determine whether or not a user should be logged
in
94
apex_authentication.login(
p_username => :P101_USERNAME,
p_password => :P101_PASSWORD );
96. Authentication Scheme
— APEX can use a number of different
Authentication Schemes
— APEX Credentials
— Custom
— SSO
— LDAP
— Database Schema Users
— Open Door
— HTTP Header Variable
— None
96
97. Authentication Scheme
— Regardless of which one you choose, the method
which APEX uses to validate credentials is largely
the same
— Pre-Authentication Procedure
— Authentication Function
— Post-Authentication Procedure
97
99. Authentication Scheme
— Authentication Function
— Can be one of the following:
— -BUILTIN-
— APEX User Credentials
— -DBACCOUNT-
— Database Credentials
— -LDAP-
— LDAP using parameters defined in LDAP section
— Custom
— Custom PL/SQL Function returning Boolean
99
101. ORA_WWV_APP Cookie
— Upon successful authentication, APEX will send
another cookie to the client
— This cookie’s sole purpose is to map your browser to your
APEX session
101
105. Logging Out
105
— There’s several ways to “log out” of an APEX
application
— Click the Logout link
— Close the Browser Tab/Window
— Quit the Browser
— Let the session expire
— Not all of these truly logs you out
106. Logging Out
— Close the Browser Tab/Window
— Does NOTHING to log you out
— Quit the Browser
— Expires the Session Cookie
— Let the session expire
— Expires the Session Cookie
— Click the Logout link
— Expires the Session Cookie
— Deletes the Session from wwv_flow_sessions$
106
107. Logging Out
— APEX automatically schedules a job -
ORACLE_APEX_PURGE_SESSIONS - which will
remove stale session data
— By default, it is set to run hourly
— You can alter the duration to make it run more or less
frequently
107
108. Logging Out - APEX 4.0
— The Logout URL is specified in the Authentication
Scheme
— When clicked, it will expire the session cookie and also
purge the session state from the database
108
wwv_flow_custom_auth_std.logout?
p_this_flow=&APP_ID.&p_next_flow_page_sess=&APP_ID.:1
The Current Application Which Application to Run Next
109. Logging Out - APEX 4.1 & 4.2
— The Logout URL is specified in the Authentication
Scheme, but is much simpler
— When clicked, it will expire the session cookie and also
purge the session state from the database
109
112. Summary
112
— There are a LOT of things that go on when
rendering or processing an APEX page
— Fortunately, APEX abstracts most of the complexity,
making it easy & efficient to use
— Understanding the discrete steps will help make
you a better and more secure APEX developer
113. Download
— This and all other Enkitec presentations can be
downloaded for free from:
http://enkitec.com/presentations
113