Browser History

  • Thread starter Thread starter Simon
  • Start date Start date
S

Simon

Hey gang.

We have an installer CAB that basically talks to the server and pulls down
files that we require.

Currently we need to build seperate CAB's for seperate servers, sign them
etc to have the server IP included in them.

This installer CAB is linked through a download. Is there any way we can
bypass having to store the server IP in the CAB and auto-detect where it came
from somehow? I don't think there is but an idea popped up about if the app
could read the browser's history and look for our server in the history, the
installer could use its IP dynamically from that.

Is this possible or is there any other alternatives you guys can think of?

It's kind of the chicken & the egg scenario. I don't think its something
easily solved though.

Thanks in advance!
 
Or if we could author something in PocketIE to set a setting somewhere that
our app could then read that would work as well but I'm not sure if there is
such a mechanism in the browser sandbox.
 
An installer DLL in your CAB could determine what server the device is
connected to and update some configuration file on the device during
install, I guess. You don't say what sort of download we're talking about
(the guy clicks on a link in IE? the 'program' is installed on the device
via ActiveSync?), so we don't really know what's going on.

Paul T.
 
Thanks so much for the reply!

Typically customers go to our download URL, click a link and it downloads
our installer CAB which is really just an installer application that will go
and fetch a config xml file off the web. The URL of that XML file would be
nice to somehow detect the server url from where the CAB was installed to
begin with.

How would a setup DLL discover this URL from Pocket IE?

Thanks again,
Simon
 
Thanks so much for the reply!
Typically customers go to our download URL, click a link and it downloads
our installer CAB which is really just an installer application that will
go
and fetch a config xml file off the web. The URL of that XML file would be
nice to somehow detect the server url from where the CAB was installed to
begin with.
Click to expand...

We somehow changed from English to something else here! ;-) Yes, since you
are simply being downloaded via browser, there's no obvious way to tell
where you came from. I suppose that the installer DLL could ask the
browser, in one way or another, maybe by finding the browser window, finding
the URL editor line, getting its contents, what page is currently loaded.
However, that assumes which browser is being used, which might be a bad
assumption, or means that you have to code for all possible browser
programs. It would work fine with PIE in WM5, it seems from looking at my
device sitting here, but not in Opera Mobile, maybe.

This is a problem that, it seems to me, is better fixed on the server.

Paul T.
 
Ok thanks for your feedback. Your concerns about various browsers was one of
my concerns as well with the introduction with Opera Mobile being shipped on
HTC devices.

I thought I would ask incase there was a scenario I had not thought of that
could work in our case.

Unfortunately a server change doesn't solve this since the server can't
dynamically store any setting on the device that the installer could read.

Additionally we couldn't extract the CAB, inject a config file, re-cab
because of the requirement of needing signed CABs.

Thought it was worth a shot :)

Thanks so much for your time.
 
The idea was to try and find a way for our production build system to only
build 1 CAB file, from which we sign @ verisign.

Maintaining seperate CAB files per server is what we do now, and sign @
verisign which has been taking >1 week.

If there was a way to automatically detect the IP then we could deploy our 1
CAB to all our servers.

I was mentioning that the server itself could repackage the CAB embedding
its own IP inside the CAB but then it would be unsigned again.

Hopefully I'm making sense :)

Thanks so much,
Simon
 
Yes, but why don't you buy a certificate from Verisign (or whomever), and
sign the CAB with that locally, rather than 'sending it out' (I didn't know
*that* was even possible; I thought everyone was signing their own CABs with
certificates that they owned)?

Paul T.
 
We used to do that. I believe one of my coworkers would sign all the dll's,
cab, etc and then Verisign/Microsoft finally released the mobile2market I
think its called which is the 1 step signing process online. So we converted
our account to this process.

However now this process takes weeks. We upload our CAB and sit and wait. We
call and call and don't get much answers from Verisign. Weeks pass then we
get our signed CAB.

It's an EXTREMELY painful process and is hindering our software release
cycles.

I think we wished we never converted to that new process. But we were told
it meant we didn't have to sign each dll, cab ourselves, more of an online,
submit, sign, done process. It's been nothing close to this though.

I'm not the person who handles this for our company but our RIM BlackBerry
automated builds can actually self sign on our build system.

Anyways I digress. Fealt like I should harp ;)

Hopefully application distributions become more glorious in windows mobile 7.

Thanks so much for all your time,
Simon
 
[...]
Additionally we couldn't extract the CAB, inject a config file, re-cab
because of the requirement of needing signed CABs.
Click to expand...

Can you change the name of the CAB file without needing a new
signature? If so, maybe you could encode some information in the
filename. If the DLL can see the CAB file name and you can include
enough information in the filename to figure out what server it's
from, that might offer a solution. I haven't tried any of this, just
an idea to think about.

Also, some file formats will ignore a bit of extra data at the end.
You could see if the CAB file will let you get away with that.

----Scott.
 
Back
Top