Goals:

• Switch AGTEK website over to https
• Provide and integration to the Apps section of AGTEK Acccess
• Update to a more general/capable language base (from asp to php)
• Give content control over to a variety of non-technical stakeholders (support, marketing, training, etc.)
• Provide modern conveniences like shared authentication integrated with the license system, reset passwords, capture email contacts, better insight to website usage patterns (who at a company uses support)
• Hand off 95% of website function to a more appropriate department

PHP - AWS server - SQL for data - SSL protected

The current test server that will role into the base server is here: http://testweb.agtek.com/ I'll change the DNS when appropriate to reflect the change:

NOTE: This server does currently support the active website for form processing so do NOT leave it down and take care on rebooting. Also, the process of turning on certificates caused a problem when originating on the current AGTEK websites. Most likely due to change between hosts

Some pages like videos and downloads require user authentication to be accessed. On any protected page the following php include (protect.php) is placed to both check a session variable 'accessp' for a setting of “yep” or send the user to the login screen while remembering the page the user was attempting to access. Protect.php looks like this right now:

<?php
session_start();
$url =  "http://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}";
$escaped_url = htmlspecialchars( $url, ENT_QUOTES, 'UTF-8' );
$_SESSION["lastpage"] = $escaped_url;

$access=$_SESSION['accessp'];  // Set the access variable = to the session variable accessp
		 
		 if($access<>"yep")   // check to see session check is correct
		 {
		  //header("Location: /login.html");
		 header("Location: http://testweb.agtek.com/login.html");
		  
		 //echo "<span onload='droploginFunction()'></span>";		  
		  
		  //echo "<script async='async'>document.getElementById('loginscreen').style.display = 'inline-block';</script>";
		  // echo "<script >document.getElementById('myDropdown').classList.toggle('show');</script>";
          
		  // header("Location: #loginscreen");
			die();
          }
?>

Authentication server code methods (from Mike A Email)

Here is theAPI methods you can use to try to log in.

Login:

https://beta.agtek.com/AccessWeb/wa2/api/connection/open?userid=mjallison@agtek.com&password=foo

The response is a JSON object that looks like this:

{"userid":"mjallison@agtek.com",
"firstname":"Michael",
"lastname":"Allison",
"phone":"925-216-7016",
"email":"name@example.com",
"customer":"Agtek", /* this is the customer ID */
"isadmin":true,"
isenterprise":true,
"err":"",
"operations":null,
"code":0,
"events":null}

If code is zero (0), it's good. Non zero will mean some sort of error occurred.  The value

of "err" is a string version of the error code. It's more human readable. It has not been 

localized and is server speak. This is what a failure looks like:

{"err":"Password authentication failed for mjallison@agtek.com",
"operations":null,
"code":100,
"events":null}

It's most likely you will receive this because of bad user id or password.
Other errors I can imagine you getting would be for network conditions or
if a corporate firewall/proxy server gets in the way. I don't know what those
error values would be. That's what testing is for.

 

You can ignore "operations" and "events", it's even possible I will make them go away. 

They are there because of the application machinery getting involved at a very low level. 

Likely these values will always be "null" when you make this call. 

 

Token login is available via /validate, but since you are not saving tokens, I won't detail it here. 

 

This code is not yet deployed on Beta, I will do so later today.

Authentication currently uses a SQL database for the comparison but ideally will use the access key system to set session variable. If we find we want a different login page or session variable, changing the code above to reflect that will propagate the change easily.

Currently the following pages are SQL driven with individual tables in the “agtekweb” database. Whenever possible I've tried to create a series of pages (admin pages) that allow adding, deleting, and editing these databases without resorting to the command line.

Software Download Overview: http://testweb.agtek.com/software.html

Individual Program Download: http://testweb.agtek.com/programpage.html?program=Earthwork%204D%20Suite

Hardware pages:

• Printers http://testweb.agtek.com/printers.html
• Laptop Videohttp://testweb.agtek.com/laptopvideo.html
• Desktop Videohttp://testweb.agtek.com/desktopvideo.html
• System requirements Windows http://testweb.agtek.com/systemreq.html

Videos: Videos are a single page driven by database for protection, title, program, and link Access files

The Access Files are stored under the corporate website under Web Materials

Inquiries and Logins are logged for both errors and sources for viewing just in case. Also logged are webinar views, etc. I have seen issues with forms in the past where having logs has saved me when emails have somehow failed. Also, we had a case where a customer had given out information to Trimble and the IP address created a record showing our site being accessed by Trimble which we called them on.

Admin Page - Needs authentication added http://testweb.agtek.com/agadmin.php

Allowing different Stakeholder to keep their data up to date

Support System pages - Peter

Video pages - Greg

Marketing/Sales - Takeoff Services list, modeling services list, Webinar landing and other supporting pages

Software downloads - Ted

Authentication - Derived from license server -

Marketing pages (product text)

Using an include for some header information including CSS versioning to allow forcing CSS updates through renames. Currently some small CSS changes don't propagate to existing users because of browser caching. It's not practical to change all pages other than an include

These are the assigned page ID's currently in use. The master css file is here: