Maintain consistent design & chrome across multiple websites - html

In the same vein as the microservice architecture approach we're currently looking at splitting our legacy marketplace application into multiple, smaller sites. We've already carved off the checkout portion and soon to follow will be the seller portal, user portal and registration pages. Each site will be completely separate and have its own domain, data access etc.
The problem is: how do we maintain consistent site chrome (i.e. header & footer) across multiple websites? For the checkout site that we've already split off we were prepared to drop the site chrome but that's going to be a much less acceptable solution for future projects.
The ideas I've had so far are (assuming we don't want to simply duplicate the header and footer in each site):
Put the necessary HTML in a nuget package and install it in each site that needs it. This should be fairly easy to do but has the disadvantage that any change to the chrome means every site needs to be updated and redeployed. Also, it limits us to .NET for all future sites (maybe not a real concern?).
Serve all our sites through some kind of proxy site that injects the site chrome into the HTML before serving to the client. This way the site chrome is actually its own application and can be deployed independently of anything else. Disadvantage: I haven't really got any idea of how to implement this; I wasn't able to find anyone else trying anything similar on Google. Also, it might be fragile even once it's up and running due to interplay between the chrome app and the content app.
Has anyone else solved this problem before? If so, what approach did you use?

Related

ASP.Net Page rendering CSS Enabled Pages Differently When Deployed

I've been working a web app in ASP.NET. I have tested on the local computer (localhost) and the web pages are rendered as I want them. But each time i deploy the entire project to the server, text, forms could get displaced, arrangement of divs is entirely different. I'm trying to go through my CSS and testing as well, but can't seem to find what the problem is.
Please, is there anyone that has experienced similar situation and what was the solution?

Content Security Policy: If set, cannot load script from bookmarklet. Is a browser extension granted clearance?

I'm working on browser automation tools (working at the JS level). It's pretty clear that loading external script can be considered an XSS attack. A few months ago I was able to run my scripts on Github.com so long as I served my js resources over HTTPS.
But this is no longer the case, i.e. Github has implemented an elegant standards-compliant barrier to this:
This is a great step forward I think: we can specify to the clients that we want them to put a more secure perimeter around our site's sandbox.
On the other hand it is making the options more limited on mobile platforms, though that's not entirely true because it's entirely possible to produce a standalone browser app which has these extension features built-in. Not exactly gonna be easy to accomplish compared to a browser extension, though.
Is it still possible to work around this with a (codesigned and reviewed) browser extension? What sort of user experience impact might this have? My hope is that it will be possible to set this up so that end-users only have to go through a short one-time setup. It's apparent to me that at least Google is making it so that Extensions published through their portal is distributed at least "reasonably" securely, and I imagine Apple (and eventually Microsoft) would be following suit for Safari and IE. I am only interested in Chrome and Safari for now (primarily Chrome for now).
If it turns out that somehow even extensions are subject to the content security policy, how might I write an extension that can reliably manipulate a page for me? I'm fairly sure this can't be the case as it would be the death of something like Tampermonkey.
Oh I just needed to read a little further (oh Github, you're awesome):
https://github.com/blog/1477-content-security-policy
The answer is yes! User configured scripts should always be granted clearance! (but we are off to a rocky start it seems)
I actually think there's significant opportunity for social engineering happening here; "Install this bookmark in your browser to use our cute emoticons in forums!" "oh bookmarks can't be viruses, right?"
As a workaround, you can tell your bookmarklet to load an external CSS stylesheet with your JS code injected. This bypasses CSP. Have a look at my answer to a similar question.

What technologies should I use to build gmail extensions

I'm looking for some advice on what I "should" research for a particular project I've been asked to keep in mind. I've been doing so for roughly 3 days by exploring various Google technologies, but none of them seems quite right.
I need to put together something for gmail that's roughly equivalent to something I've put together for Windows Outlook. I'll explain in brief therefor what I've done for Outlook users, to give you a feel for what I'm looking for. I put together an Outlook C# AddIn that when loaded by Outlook on startup adds a number of clickable tabs, buttons, and other assorted interface elements to the Outlook interface. When you click them the C# code in my Add-In is invoked in various ways to carry out various activities, like archiving the email message that's currently selected in a remote database managed by one of our web applications. It does this by calling a variety of Outlook C# APIs that are available to any loaded AddIn, to extract or manipulate various Outlook "objects". Another thing it does on a button click is bring up a web browser the AddIn creates from a .Net class "webbrowser control" instance, essentially adding chrome to the IE "engine". It also adds what it needs to to the DOM of that web browser to make a large number of Add-In C# functions callable by javascript code that might be running in pages of that browser, essentially giving our web applications a way to "ask" my AddIn to create Outlook contacts, tasks, messages etc on behalf of that application. The gist of it is that the UI I add to the Outlook application can be used to make various web service calls to our applications (based on the state of various Outlook "objects" made visible/manageable by way of the Outlook C# API), and the state of the Outlook application can be manipulated by javascript code running in web application pages that happen to be loaded in the web browser it creates.
I need to support "similar" functionality with respect to the altogether different gmail beast (rather than a Windows application a browser based web app). I feel a bit like I've been spinning in circles the last few days, while investigating. I began by researching gmail Sidebar and Contextual gadgets, to add some roughly equivalent UI of my own to gmail, but found fairly quickly that I can't really get to any gmail APIs using them, only try to shoehorn what I've got into a set of triggered gmail "behaviors" supported by contextual gadgets, which I came to realize isn't really sufficient to support what I want. Eventually I navigated my way to the set of developer pages describing Google Apps Script supported functionally, which seemed for a time like "the way to go" to provide me with hooks into gmail APIs. I played a bit with them, making a web app script to collect the subject lines of all my gmail messages and dump them into a UI also built by the script, just to get an experimental quick feel for how things fit together. The script works, but it seems pretty slow, taking roughly a minute to collect and display just 57 email subject lines. And I can't really figure out how to get any script built UI into the gmail user interface. I tried building a side bar gadget with the URL of my app script referenced (with no HTML or javascript in the content tag body at all). An area is allocated to the gadget ok, but my script UI never appears in it. After playing a bit unsuccessfully to get my script to run in an iframe in a completely different context, just experimenting again to see what I might be able to do, I'm beginning to get the impression that some security related caveat prevents it from building/displaying its interface in either an iframe or a gmail side bar gadget, though perhaps I'm just missing some essential piece of information.
My question is a bit big I know, but "should" I be looking to other Google technologies to build the sort of thing I have in mind, or am I "roughly" following a tenable track. I'm looking for some rough architectural advice I guess, some hints about what maybe I should further explore.
With Google Apps Script you cannot add anything to the Gmail interface. Putting it simply, it will not do what you want.
Now back to your problem, if sidebar and contextual gadgets are not enough for you. The only solution I see where you can really manipulate the page is via an add-on/extension/script installed on the users browser.
This approach is powerful, in the way that you can change the page as you like, but has its shortcomings as well. First, and more obvious, it's somewhat browser dependent and installed locally on a browser. Meaning that if the user switch computers or browsers, he'll need to re-install your add-on.
Also, you're somewhat dependent on gmail's "internal" structure. I say "somewhat" because that depends on how you coded your app. But they may make a change and break your app instantly, without any notice, since gmail's html-css structure is not a "published API".
Well, that's my 2 cents. I hope it helps.
Use JSF and rich faces. this can give u a google gmail like looks and development with this is very easy and fast.
Happy Coding

Desktop app/widget development using web technology stack

I want to develop a desktop application/widget, and would love to use a web technology stack. so I can...
Reuse existing skills
Run on multiple platforms (OsX, Windows)
Update application code without having the user upgrade (part/all of the code gets downloaded from the web)
Running in a browser is probably the best option, but one thing that is getting in the way is the browser's chrome (frame, tabs menus etc.) and background, as I want to create a transparent application (e.g. a semi-transparent, round clock that would display on top of other apps).
I'm thinking that a custom version of a browser (chrome or firefox) is probably the answer. All I would need to do is have a shortcut like:
...\chrome.exe -transparent -no_chrome ...\mywidget.html
Seems to me like a fairly obvious need, so before I consider forking chromium, I'm thinking there must be something like this already.
I know there's http://awesomium.com/ ($2,900 license cost), but it is an overkill as I don't need to embed a browser into a desktop app, API and all, and the cost is prohibitively high for a low-cost, limited distribution app.
There is also http://mozillalabs.com/chromeless/ but it doesn't seem actively maintained.
In addition, for both options, the installation overhead is huge (installing a full-fledged browser for the sake of running a widget).
Any suggestions? (please not Adobe Air - I want to use a standard web tech stack)
Take a look at this discussion for several options
http://news.ycombinator.com/item?id=2829126
-FT

Is it possible to make part of the browser transparent to display underlying desktop/windows in a web app? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am developing a web application (meant to run work as a rich client and able to afford requiring any (even nightly build) version of Firefox of Chromium).
The application interface background is meant to be transparent (showing underlying windows or desktop). How can I achieve this? Following standards does not matter but would be nice.
Primary target platform is Linux.
UPDATE addressing comments and answers received to the moment of 2010-07-07T01:44Z.
Technically it's nothing about code interaction and breaking the "sandbox". It's about window composition. I even think it can be implemented pretty easy in a compositive window manager without a browser even knowing of this - just replace some useless colour (for example "fuchsia" was widely used for this during Windows 9x age) with the underlying layer content.
Politically, this can and should be a restrictable function (like local file and webcam access, for example), which can be allowed for trusted intranet applications (local web-tech-based rich client applications seem to be a trend beginning - Firefox and Chromium implement more and more features to facilitate this) and forbidden for unknown 3-rd party websites (but this would require more complex interaction between a browser and a window manager).
The reason why would I like it is that I want to build a cross-platform (Linux, Windows, Mac), zero-install, fancy-looking rich client application (not meant to be served as an Internet website) with web technologies (like HTML5, CSS3 and JavaScript). I even will probably seek to use some browser-window-less tech to run it (I've heard about Mozilla Prism and XulRunner, KDE and Windows offer to use HTML for desktop widgets, Chromium is meant to offer something alike, etc.)
This is not possible "currently", but there's no technical reason why a browser couldn't provide a proprietary API for this, using non standard html/css/js.
However, that's what it would take, a browser to actually implement this functionality and then expose it as an API, and even then it would be browser specific.
UPDATE (as some people have perhaps misunderstood my answer???):
I'm giving technical context to the question. Of course noone's ever going to implement this, but I'm saying it's technically possible.
Also, doing this would not break the sandbox model. The browser itself (forget an API for a second) could implement transparency any way it wanted. Once it that it could hook it up to it's Javascript engine, and create a stupid call: Chrome.Element("").WeirdTransparency()
UPDATE to Questioner's Update:
to your point:
The reason why would I like it is that
I want to build a cross-platform
(Linux, Windows, Mac), zero-install,
fancy-looking rich client application
(not meant to be served as an Internet
website)
AIR kinda covers 90% or your requirements. It still needs a small install, but apart from that, you're running...
This is possible in Electron. By setting a transparent background on the body.
I'm sure browser developers would need a lot of "inspiration" - aka $$$ to do this. It's currently not a feature that a whole lot of people are looking for.
Since standard compliance is very high on the priority list for all browser developers, making this out of the box would be a problem. Namely because there is no CSS/HTML support for it, and the standard is to have a white background. This means that they would need a custom "flag" somewhere in the markup to tell it to switch off the white background.
This would be exclusive to the browser that implements the "feature" and anyone else using any other browser would not be privy to the it.
Somehow you can get the background image of the desktop, set it your html background, and code any app in it. when you do this concept with active desktop in desktop configuration, I get to see this. ( I maximize the web page and lock it - to make it feel like my desktop )
For getting the background, I am putting the location of that in my PC right now. But I think there should be some programmatic way to do it.
This works for our local desktops. But the idea you are talking about, you definitely require Prism like thing. But Firefox looks like it stopped that project for all. (I keep the dump of it in my PC, though). So Recent users would not have prism even if you guide them to install it on their PCs.
And then, This works if the image is full sized to fit the desktop. Otherwise, We have to repeat it, and the whole desktop looks absurd. I often try to write AIR ( Adobe RIA platform for the Desktops.) apps for my taste of eyes.
I think you should try learning Adobe AIR. In fact, it supports all open technologies. I am not any Adobe employee though :) in case you think I am promoting AIR.