I want my website to redirect mobile users from mydomain.com to m.mydomain.com (unless they have specifically asked to see the non-mobile site).
I was doing this in my application using WURFL, but I want to enable page caching. If page caching is on, the application will never be reached to know to redirect the mobile user, and so I need nginx to do this.
Apache has modules such as Apache Mobile Filter that make use of WURFL.
Is there any good way to detect a mobile browser in nginx? I'd rather not just come up with a user-agent regex since there are so many different mobile user agents that are always changing.
I don't believe there is a dedicated nginx core or third-party module for this. Since any module would simply test the user-agent anyway, I can't imagine anyone creating a module for this specific purpose.
However, it should be relatively simple to set-up a check on the user-agent and redirect. You may find it preferable to check for Gecko/IE/webkit/opera explicitly and redirect everything else to your mobile site - that way you're maintaining a smaller ua regex, plus you'd be catering for the mobile safari (iPhone/iPod Touch) by keeping them on your main website. Its then a simple step to special-case for that browser should you wish to.
Furthermore, you should be able to check cookie contents in your nginx config to decide whether to redirect based on the user-agent's preferences.
Related
I have some content in AEM and I am planning to export those content into mobile app(react) in headless way. I am using AEM content as service, sling content exporter(Jackson) to export the content.
For example, http://localhost:4502/content/we-retail/language-masters/en/course.model.json will export some content to frontend application(react mobile app). I want to protect this API call and I should return the json response only to my frontend application(react mobile app)
Basically I want to validate who is calling AEM. In this case I want to allow only mobile(react) to call AEM and want reject all others. How do I protect my AEM content ?
The one way I am thinking is to use Apache sling referrer filter in AEM. Referrer filter will reject the request if we are not allowing the mobile app (react ) in "Allow Host". Is this correct way to handle? if there any other best way to handle this? how about using Adobe granite OAuth 2.0 server ?
Please suggest me what are the available option to protect the content in headless.
As you give the App away (and it is based on JavaScript), you cannot get full security. Attackers could use a jailbroken phone and debug or de-compile your app. But you can easily secure your API in a way, that nobody can “accidently” find the entrance. Nor the average hacker can gain access.
The simple approach = SSL + Basic Auth
Make sure, that your site is only accessible via https (= SSL). Then just add a Basic Auth password, which is hard to guess. This is simple to implement (on Dispatcher and in the App), and developers/operators could still test the API. Only make sure, that the password is obfuscated in your App. So, don’t store it as plain text. A simple XOR encryption is probably enough.
The advanced approach = SSL with client-certificates
Instead of a Basic Auth password, you could use an SSL client certificate (implement that also on the Dispatcher, and NOT in AEM). This is probably a little bit over-engineered, and it can still get lost. But now the attacker must de-compile your App to extract the certificate. The Basic Auth password could theoretically be “found” in other ways – or it could be attacked with brute force.
PS: In both cases you need to monitor your API with some intrusion detection. And you must be able to distribute new passwords or client certificates to legitimate clients.
PPS: Mobile Security is a huge topic. This could not be handled in a StackOverflow question. But to stop script-kiddies from crawling your API, the simple approach is probably good enough.
We are adding modern authentication (OAuth/OIDC) to an application that currently uses Windows integrated authentation for single sign on. The user signs into Windows workstation and those credentials can be used by many applications with authentication happening transparently over Kerberos.
Our app is a dot net web services based application and we have a client for users with browsers and a desktop client in WinForms. The browser scenario is no issue as the identity provider stores information in the browser that can be reused across applications in a similar way to WIA (IWA), but we are unsure the best way to handle the WinForms desktop application case. Currently the WinForms application opens a browser window to authenticate using the typical browser based method. The details from the identity provider are passed through the browser back to the WinForms app using a redirect and a custom protocol based URL.
This all works fine, but the user experience is not super tight and, for the case where the user is already logged in, requires them to press a button in the browser window as current Chromium based browsers seem unwilling to do a redirect without a recent user interaction.
Is there a better way?
The standard options according to RFC8252 are as you describe:
Log in via the system browser
Use either a loopback or private scheme based URL
I have a few blog posts about this and it is a tricky flow. The posts link to code examples you can run that explore the UX a little. You may find that a loopback URL avoids the need for a button click, though personally I think private scheme based URLs are cleaner.
There are UX things you can do, such as an interstitial web page to better control what happens in the disconnected browser. I have seen companies redirect to their own website after desktop logins, to make the UX better.
In the longer term I expect this to be replaced with API Driven OAuth Flows so that you never need to leave the app. For now you may have to live with some UX linitations, but it is the right flow from a security viewpoint.
Does anyone know if you can expose a superset or chart on a mobile device? Has anyone explored it?
I have researched github and stackoverflow but have not seen anything posted.
There are 2 considerations here:
How to run Superset (the service / code)
Superset is primarily a Python backend application and typically runs on your computer locally or in a cloud environment (like on Amazon Web Services or Microsoft Azure). If you're running Superset locally (e.g. via Docker Compose), you can navigate to localhost:8088 and the Superset backend will serve you frontend code to your web browser. If you're running the Superset backend in a cloud environment, then you'll need to do extra configuration in your cloud environment to expose it safely to a publicly accessible port (which can then be mapped to a web domain you purchased, like "awesomesuperset.com").
How to access charts from a mobile device
Once you've configured Superset to be accessible through a port (that maps to a URL your mobile device can access), you'll be able to navigate to that URL from your mobile web browser.
Superset, at the moment, unfortunately isn't designed for mobile devices. There's been some informal discussion about this in the community, but it's a big undertaking!
So even if you got this all working, I'd generally recommend accessing Superset's UI from a laptop or desktop computer!
Superset in its current state is not designed for mobile form factor. However you can cleverly make use of the grid, you can build a simple mobile ready dashboard. I had created a simple status dashboard for mobile viewing, just using the Big Number chart, pie chart and simple line chart. Not other fancy charts were used and indeed the line chart was limited to 10-15 data points. Just sharing if this helps you.
Note: this would not be a interactive page.
For superset as a whole;
It has, to some extend, some responsiveness but not %100, i.e. the menus will behave according to the media width or height as your window resizes etc. But dashboards will not be responsive.
To display a single chart/dashboard in a native mobile application;
Get an authentication token from the api, and then use (&standalone=true) query parameter in the call to superset. Then the web view (or other browser controls) will display the chart or dashboard.
To display a single chart/dashboard in a web page;
For this, you will need superset to run in an iframe and put a query parameter (&standalone=true). But this is not automatic in its current state. What ever configuration you do, you will not pass even the login screen. To overcome this, session manager must be changed ("app.session_interface") to be able load session state from the URL, not from cookies, in a secure way. This can help you start. But bare in mind that, this is not a fully secure method. Meaning, if the URL you are using to get the dash or chart contains a session state generated by an admin, that means you are giving a free pass to everything in superset.
It is really unclear what to use when you want to put ads on a cross-platform web application published as is on a website and also on the stores through phonegap.
Admob, Adsense ...?
Moreover, which one has a simple html/js integration system?
For now, I am using inmobi and their js api is very simple and nice, but I have cross domain problems...
Can you help clarify ?
this is Akshay, JS Dev, InMobi. InMobi is an ad-distributor. The ads/creatives are made by the advertisers. Also, these ads are placed in an iframe so that these ads cannot access the data present in your page, thus providing security. Because some ads try to "burst" out of the iframe, chrome throws the warning. However, these warnings can be safely ignored and will not affect your website's functionality.
That being said, InMobi's javascript is not responsible for these issues, rather the advertiser and InMobi has no control over this. There are some ad networks which require a dummy page to be present on your domain. By using such ad networks, the chrome warnings disappear (because the iframe is on your server and cross domain problems do not occur). However, by doing so, the ad has complete access to your webpage, compromising security.
For our e-commerce service running on AppEngine we would like to offer the option for customers to run the stores on their custom domains (eg: www.mystore.com instead of www.enstore.com/mystore).
From a user perspective, I'd like them to enter the domain name they want to use in their preference screen and tell them how to configure their dns.
I know how you normally add domains to an AppEngine instance (through Google Apps) but I'm not sure you can automate that. And even if that's possible they would be all (hundreds) listed on our google apps page.
Anyone know if this is possible/if there is a good way to do it?
I don't think there is a way to add domains "programatically" to an AppEngine instance. Apparently, domains can only be added by using the Google Apps method that you described. This is confirmed in this SO post: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine
The only options that pop to mind are the following:
HTTP Redirection
Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up mystore.com and www.mystore.com to redirect to www.enstore.com/mystore. There are some obvious disadvantages with this method that might not be acceptable. First of all, with 301 and 302 redirects, the users will still be forwarded to the registered AppEngine URL: www.enstore.com/mystore, and it will show in their browser. In addition, choosing between a 301 and 302 redirect can make SEO tricky, since you'd have to get into how search engines behave with these redirects. For example most search engines will not use the original URL as a source for keywords when you use a 301 redirect.
In addition to 301 and 302 redirects, some DNS providers (like DNS Made Easy) also provide what they call a "masked hidden-iframe redirect". The page will render inside a hidden iframe, so the URL does not change in the user's browsers. However this makes SEO even more tricky, and it will not allow users to bookmark internal pages, or to reference them easily.
As you can see, this option is less than ideal, but it is one option to consider in some situations. Also note that at the moment, HTTP Redirection using 301 redirects is the suggested workaround for the Naked Domain Issue 777 on the AppEngine issue tracker.
Reverse Proxy
Another option could be to set up a small server somewhere else, like a small Amazon EC2 Instance, and set up a simple reverse proxy. You would be able to set this up very easily, just by using Apache and mod_proxy (or various other alternatives). This would allow you to ask your clients to set up a normal A Record pointing to this instance, while the Apache HTTP server would be acting as a proxy to your AppEngine.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically set it up with one line like these for each VirtualHost (for each client domain):
ProxyPass / http://www.enmystore.com/mystore/
The configuration of the remote proxy could be easily handled by your back-end software.
This is a neater solution which gives you plenty of control - but there are obviously some costs for these benefits. First of all, there is the expense to host the reverse proxy. You would also be adding another point of failure, so you have to add this to your high-availability plan. In addition, if you are serving some pages through SSL it can become quite complicated.
Another option is to have each customer sign up for google apps, and then add your appengine app to their app. That way they can manage the url. They will need to use a cname for this, so urls will be limited to something like 'store.customer.com' You will have to support the multitenancy off of the host-header, but that isn't hard to do given that you already have a way to support multitenancy already. You might want to do the setup for the first couple of clients yourself so you can document the easiest way to set it up.
The rietveld code review app does this as you can add it to your google apps domain. See http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps for more detail.
The preferred option is probably to offer your solution through the Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html
We did something similar to Daniel Vassallo second proposal.
We created a python app on the Heroku cloud
(there is no limit for connecting custom domains).
This app is using python requests 1.2.0 lib to get the correct page from your app engine application according to the request domain.
all you need to tell your clients is to put your Heroku app url as their CNAME
For naked domains you can always use wwwizer