REKA Application Platform
Official Acceptable Use Policy (AUP). This policy outlines access rules, safety principles, naming guidelines, and project handovers.
AUP Compliance & Availability Checker
Check if your proposed REKA subdomain complies with the rules and search live server registry availability.
1. Objective
This policy explains the rules for creating, deploying, and owning applications on the REKA platform. It helps protect university data, ensures clear accountability, and separates administrative work, academic projects, and open sandbox testing.
2. Platform Architecture & Instance Scope
To protect university data, REKA is divided into three separate environments based on who will use the applications and how sensitive the data is:
ia.unimas.my
This instance is strictly for administrative work, automating processes, and official university operations. It is restricted to UNIMAS departments and units.
aa.unimas.my
This instance is strictly for official academic applications and systems that support academic processes (such as course registration, online applications, transcripts, viva, and thesis submission).
ireka.my
This is a completely open playground and testing environment. Students, external users, and developers can use it to try out REKA, build prototypes, and run commercial projects.
3. Mandatory Ownership & Governance Requirements
To maintain operational continuity and clear responsibility, application creation and ownership are governed by strict access rules:
If you build or host an application on either the Administrative (ia.unimas.my) or Academic (aa.unimas.my) instances, you must include at least one (1) active UNIMAS Staff member as a registered co-creator or owner in the application settings.
5. URL Subdomain Allocation & Namespace Governance
Every application can have a unique, accessible web link (such as <app-path>.aa.unimas.my). To keep university systems clean and organized, your web links must follow these rules:
-
Be Specific: The link must clearly describe what the application does. Do not use generic or broad names like
register,admin, orportal. For example, usecourse-registerinstead ofregister. -
Branding & Initiatives: If the application has a specific brand or official initiative name, it is highly recommended to use it. Examples include
edonation(for the eDonation System),ipserv4all(for the IP·SERV 4 ALL Initiative), ortraqr(for TraQR - QR File Tracking System). -
Include Faculty Abbreviations: If your application is only used within a single faculty or department, you should include the standard faculty abbreviation in the link (for example,
viva-fskpm.aa.unimas.my). -
Reserved Keywords: The paths
io,create,design, andcoreare strictly reserved for platform operations and cannot be used. - Path Dispute Resolution: If there is any conflict, dual claims over identical subdomains, or ambiguous requests, TAHODC has the final say in assigning, altering, or revoking links.
6. Security, Safety & Regulatory Compliance
All applications must be safe. Applications built on this platform must never threaten the university’s network, data, or reputation.
Every app built on the REKA platform must satisfy strict safety requirements. If an app performs illegal activities, contains malicious content or scripts, leaks data, or leaves the university open to security hacks, TAHODC will take immediate action.
All security violations will be processed and penalized in accordance with the Dasar Keselamatan ICT UNIMAS, which may result in removing the app immediately, suspending developer profiles, and disciplinary actions.
7. Project Handover Lifecycle & Quality Assurance
To make sure applications are secure, stable, and easy to maintain over the long term, we follow a specific process when transitioning projects into TAHODC custody:
Target Handover Scope
This process applies strictly to any application developed outside of TAHODC or not initiated through the formal JKSPA (Jawatankuasa Saringan Pembangunan Aplikasi) process that is scheduled to be officially handed over to TAHODC.
Project teams must submit a formal assessment request to TAHODC before the app can be handed over.
TAHODC will check that the app's user interface (UI/UX) style, system database design, and coding methods fit their standards.
Once TAHODC gives technical feedback, the project will enter a mandatory cleanup period. The creators must adjust, optimize, or fix the platform code based on TAHODC's feedback before the center accepts final custody.
8. Production Deployment: Dev to Live
To ensure platform stability and quality, all applications must go through a formal registration process before transitioning from Development to Live (Production) mode.
An application must be formally registered through the REKA dashboard before it can be requested for a transition to Live mode. Unregistered applications will remain locked in Development.
The registration request will be processed by the REKA Committee. If the app meets all criteria, it will be transitioned to live. If it falls short, the committee will provide actionable feedback for necessary revisions.
9. Intellectual Property, Sunsetting & PDPA Compliance
PDPA 2010 & GDPR Compliance
Compliance with the Personal Data Protection Act (PDPA) 2010 is not required for internal university applications. However, it is mandatory for applications processing personal data in commercial transactions.
Subject application owners must provide a clear PDPA notice (configured using the REKA One-off Screen) and officially appoint a Personal Data Protection Officer.
Cookie Consent If the application requires a GDPR cookie-consent banner, it can be easily enabled directly in the App Settings.
Intellectual Property
Apps on ia.unimas.my belong completely to UNIMAS. Academic apps on aa.unimas.my follow the UNIMAS IP policy. Projects on ireka.my belong entirely to their creators.
6-Month Sunset Rule
To save server resources, any app left inactive (no logins or transactions) for six (6) consecutive months will be automatically switched to 'Dev' mode, which restricts public access until reactivated.
🔒 Core API Gateway Restriction
Apps are strictly blocked from connecting directly to core university databases. Instead, all systems must safely fetch or send data through TAHODC's secure API gateways using proper authorization tokens.