I'm struggling with the best/most economical way to allow some of my clients access to their product and pricing data, so they can log on and place product orders over the Internet.

My original idea was to have Sesame generate an html page that could be uploaded to my website, which would allow client data entry for delivery instructions and quantities, etc, and then push a Submit button which would send the html order page  to my email for processing.   But that seems like it might become quite involved, and maybe over my head.

I had a new thought - could I have customers log onto a workstation on my network that was a dedicated workstation only for a Sesame client, which the customer could then gain access to only their data via a userid and password?   That way I could just design an order screen that they could enter and print themselves on my printers, sparing me the ordeal of html - java - submit - programming, updating.
                If so, can anyone here suggest how I might pull that off?  I've used gotomypc for many years (it's great), and have a technical support question in to them right now about whether they have a product that would allow this type of very specific access.   But I thought some bigbrain type on this forum    might have an alternative method that would be better.

Thanks!

Hi Hammer,

thanks for the quick reply!    Once the client gets to the Sesame icon, I'm confident I can (with some forum help!) get the ordering set up just as you describe.    My more general question is - does anyone know how specifically the customer 'comes in on my remote workstation'?   I'm talking about an inexpensive/elegant 'taphammer' technique (I know there are fullblown commercial solutions to that, but we're small and don't have the resources for the 'sledgehammer' solution). 

As a second question to deal with your insightful comment about 'session control' to deal with customer B trying to get in while Customer A is entering an order .... can I have multiple Sesame client licenses on the same workstation?  Icon A and Icon B?

Remote Desktop will disconnect an existing user after prompting you for authorization to do that.  You can also change the ports on Remote Desktop, but again it only allows one concurrent logon.  Host system must also be XP PRO or higher. XP HOME does not support hosting Remote Desktop, but HOME and WIN98SE systems can make Remote Desktop connections to a host.

A free remote access program is UltraVNC ( http://www.uvnc.com/download/ ) that I believe does allow multiple simultaneous connections.  And you can define different ports so each user could be using a unique connection.  That would also involve some port forwarding on the routers and firewall configurations.

FWIW: I know that a browser-based solution sounds intimidating, but it's really the right way to go with this...

lksseven wrote on Jan 30^th, 2009 at 7:02pm:

In a nutshell, yes. It's going to be a much better choice for the long run. The specifics of implementation, like where you host the web pages and whether you use a report or a command button, will vary depending on the requirements but if your clients do not actually own copies of Sesame then a browser-based solution that creates orders that can be pulled into your Sesame database is going to be your best bet.

lksseven wrote on Jan 30^th, 2009 at 8:55pm:

That's an interesting suggestion for the future, but it occurs to us that it already exists in another form. It's called our Trial Version. Your Customers can download and install the Trial Version for free. If your Sesame Server is internet-accessible, they can hook up to it as clients, just like they would with a paid version. The 30 day limit on databases is server-side, so there wouldn't be any issues there. You just need to purchase enough licenses for your server to handle as many simultaneous connections as you think you'll need. Hmmm indeed...

lksseven wrote on Jan 30^th, 2009 at 9:57pm:

NO MAPPING! We're actually client/server. If your IP address, as exposed to the internet is 123.123.123.1, then the Customer would set the icon to run the program as something like:
C:\Sesame2\Program\sesame.exe - client 123.123.123.1


Quote:

You could make it do that, yes.

Quote:

With this method, yes. I think this solves the various network and security and sharing issues.

Following up on Carl's setup....the clients can install DynDNS free software, and your server can confirm the incoming IP against the master whitelist.  Your server would update the whitelist by doing lookups at DynDNS.  Works great for sites with dynamic IPs.  I use it for Remote Desktop and other remote tools.

Quote:


That IP control does sound correct.  Client icon is 64.100.150.85:1030.
Router uses pinhole to redirect to internal 192.168.1.100.

But I am not sure if Sesame will perform through those paths, will need answer from Lanticans on that part.
I think that your Sesame server will also need to be set up using port 1030 and your internal clients also.

See the Help for starting your Server and Client. 

Example here:
C:\Sesame2\Program\sesame.exe  -server ServerName:1030:1031
C:\Sesame2\Program\sesame.exe  -client ServerName:1030:1031

Don't  know if you may need to add 1031 to your router pinholes.

The ports under TCP/IP are the last step of the addressing system. An IP address specifies the computer to connect to. The port specifies a protocol or server-program to connect to. For example, FTP typically uses port 20. HTTP uses port 80. SMTP uses port 25. Connecting to a particular port indicates to the server that you intend to perform a particular action (i.e: transfer a file, access a web page, send to email) using a particular protocol.

Sesame defaults to using ports 20000 and 20001, but can be placed on any ports that are not otherwise occupied. It is important to avoid ports numbered below 1024 because those are assigned to basic TCP/IP programs from the original specs of the 1960 and 1970s. It is wise to avoid ports below 8196 because those are reserved for the standards groups to assign for fixed use by programs that apply to the standards group. The highest reliable number is 65535.

It is probably unnecessary to have your client come in on fixed addresses to use the sesame_allow and sesame_deny files. Both allow a range to be specified using a wildcard character. So you can set the allow file to 192.168.0.*, for example, and allow all of the computers assigned from 192.168.0.0 to 192.169.0.255 to access your server. If you specify 192.168.*, you allow all of the computers from 192.168.0.0 to 192.168.255.255 to access your server. Etc...

Because ISPs typically hand customers IP addresses in the same range, even if your customers get reassigned IP addresses regularly, it unlikely that those addresses will be outside a 255 range. Combined with a password to access their account on your server, you should be able to differentiate your customers from the random visitor, especially since random visitors are unlikely to have a Sesame client at hand.

The trial version of Sesame will run as a server or a client, just like the commercial version will. So if you want to start getting set up, you can, without having to wait for your oder to go through. You can certainly start experimenting to see what configuration works best for you.

Mark,

Wow, your message was like a college semester rolled into a few paragraphs.  I can't tell you how much I appreciate the time you spent to help me.  That may be the piece that makes all the other pieces come together.

Regarding getting started, I've been experimenting with some form design - trying to learn the in's and out's of the Form Designer, field names, what makes sense to cross over from my QA forms, and what doesn't. 

I had recently put a Netgear Networked Attached Storage RAID on my network.  My plan was to put all of my databases and data-mining programs (QA, accounting data files, Forest and Trees views, etc) on there, and enjoy the disk mirroring security and backup convenience of the NAS.  But, I quickly learned that my live accounting data files couldn't reside on the NAS (it's client server using a Pervasive Btrieve database, and the data imust apparently reside on a workstation), but my QA data files can. 

But  I assume because Sesame is client/server  that I must have the server software and data files reside on the same computer, and then use the NAS for backup and other storage functions?
             If that is correct, then I'll need to setup a workstation to be my Sesame server.  (my accounting data has been running on an HP NT workstation computer for the last 9 years 24/7 - what a workhorse computer.  I'm worried about it expiring, and have another computer that's ready to step in when it does.  I don't think I can put Sesame on this accounting server though - it's only got 128MB of RAM, and the hard disk is not a lot of space free (a couple of gig - I think it's only a 4gb drive though - 1999 vintage!).

Thanks again for your help and time on a Sunday!

lksseven wrote on Feb 1^st, 2009 at 4:04pm:


As long as the server can access the data files as though they are on that computer, whether that particular harddrive is on that computer or not, Sesame will be reasonably happy. So you can, for example, access the data files through NFS or MS-File-Sharing, so long as the server computer and only the server computer is accessing the files. You will, of course take a speed hit for dragging the files across the network between the Sesame server and the file server.

Quote:


128 MB is not enough. Most of the work is done on the Sesame server, not on the client computers, the exact opposite from the setup for file sharing.

Quote:


No problem.

Carl's suggestion is correct, but no need to open a browser to get your IP.

Many posts ago I suggested using DynDNS,org free tools.  So, let me repeat the suggestion.

Can see your IP in the systray at any time, and others who want to know your IP can ping to yourname.dyndns.org.  If your IP changes, that change is broadcast to dyndns.org servers automatically, and the value in your systray will also be modified.  So Client can always know their IP and Hosts can always check incoming IPs against a whirelist that can be updated from dyndns.org.  A good use is also when need to make a remote connection to someonw with a dynamic IP.  Enter the dyndns.org name vs. the IP and no lookups are needed, site is treated like a static domain name.

DynDNS may be very worthwhile, but I do not want to create the erroneous impression that it is necessary to allow your clients to connect to your server which is already at a fixed address, as is the case here.