i've build a website that actually don't need cookies at all to work...
this just to avoid any problem dealing with european privacy laws, i really don't need any kind of user interaction at all on public part of pages then fully disabled cookies using this as a reference:
I would like to know how to disable cookies in Rails 5.1
now using development tools on browser, cookie store results empty and this was exactly what i was trying to do...
well, the site has a reserved area (this runs on a separated namespace)
is there a way to keep cookies disabled on 'public' part and make cookies work again inside 'reserved' namespace area??
i've tried to disable cookies inside single controllers (again using above link suggestions) without success!
only way to have cookie store empty was to operate a 'full disable' with modifications
on these files:
config\application.rb
config\intializers\session_store.rb
waiting your suggestions.....
thanks in advance!
Francesco
Related
I am helping to create a Rails app that uses Ember for a front end MVC. For the app, it is hosting user content accessed via subdomains. On the subdomains, the user can upload custom JS and CSS. What I'm wondering about is if token authentication on the root domain will be safe if stored in Ember from the custom JS people could upload and run on their subdomains?
Provided the following:
Don't use cookies on *.domain.com or use cookies at all.
They can't run (or really display it unescaped in any way) the JS/CSS on your main site.
The ember app with your token doesn't run on their sub-domain (obviously).
They can't put HTML in a file with a different extension or even Content-Type on your subdomain (or you aren't using cookies). They could direct a user's web browser there and it'd display the HTML. Be wary of phishing though (looks like it's your secure content). I can't imagine you could prevent this easily other than not using cookies -- without 100% ensuring properly formatted JS/CSS which would present all kinds of problems.
You can limit cookies to domain.com and www.domain.com, but I don't recommend it (prone to mistakes). If you don't somebody can make a GET request through CSS or ie. an image tag (not to mention JavaScript) and it'll send the authenticated cookies to your server. Remember unescaped input in their app can leave holes too.
If your token is stored in ember, and they have access to custom JS where the app is running of course it'll leave your token vulnerable. If you run your ember app only on the www.domain.com, avoid cookies, storing the token only locally/in JS, you might be okay.
If they just put HTML code in a file with another extension and direct people there it'll be interpreted as HTML.
I wonder if there's a way to tell TYPO3 to share the sessions / cookies between different domains?
We wrote an Extbase extension on a multi language / multi domain site.
We store search words from a search form in the user session. If the user switches the page language, he should get the same results as before - Without the need to re-fill the search form.
One way would be to tell the browser to store several cookies at the same time - one for each domain/language. How can this be achieved with TYPO3 / Extbase?
By default, there is no way to set cookies for a different domain - not with or without TYPO3. This is a security measure implemented in every browser (or do you want me to set / read your cookies from yourbank.com when you visit my web site? ;-))
You have to create some helper script that does this for you. One way could be:
example.com is loaded
this page includes an iframe to a PHP script (or TYPO3 site, e.g. with eID) on example.org with a GET parameter storing being the session id
the script loaded from example.org reads the GET parameter and sets a cookie with that session id (or whatever parameter you want to transfer).
afterwards the cookie is also available when browsing example.org
I have never tried this, but I'm pretty sure it will work with PHP. Maybe it's even possible with pure JavaScript, but I'm not so sure. In every case, think about what security holes you get with the explained script. In doubt sign the parameters (or require a token)!
I am using this answer here to log unique page views in my app: https://stackoverflow.com/a/15174466/1235816
I am using a cookie to check for unique visits. As far as I am aware, because the site will be hosted in the UK, I should have a message which asks the user to accept cookies or if they don't... it asks them to leave the site.
I want it to work like this... If a user wishes to accept cookies, then the 'app-name-visited' cookie should then be downloaded, otherwise if they just exit the site without clicking accept, no cookies are downloaded to the clients machine...
Is this:
1/. a correct way of thinking?
2/. possible?
The cookie law has since been modified, so this is not quite necessary any more, you only need to let the user know that they you will be using cookies.
The organisation that enforces this is the ico, which doesn't ask for permission for cookies on their site:
http://www.ico.org.uk/
Suggest you follow this pragmatic approach.
If you are wanting to comply as per your question I did some work on this a while back for rails projects which should be a decent starting point:
https://github.com/yule/threepwood
ASP.NET MVC2
.NET 3.5
FormsAuthentication
URL: domain.com/myapp
Problem area: Dynamically created PDFs returned as FileContentResult
Everything was working fine until IE8. With IE8, when the user opens a PDF and then returns to the app, he has lost his authentication. I added an expiry on the forms auth cookie and the problem appeared to be resolved. However, I later discovered that the same problem occurs in the parent app. With the persistent cookie, when the user continues in my app (domain.com/myapp), everything is fine, but when he returns to the parent app (domain.com) window he has lost his authentication. The parent app uses a proprietary authentication and authorization architecture that relies on session state.
So my understanding of the problem is that the FileSystemResult does not carry any session information and thus the session is lost. I understand that by adding an expiration to the cookie, the cookie is persisted and that enables the authorization to persist in my app, even when docs were opened.
I don't quite understand why adding an expiry to my cookie transferred the problem to the parent app. So, I was wrong, this has been happening all along in the parent. Interestingly, when I hooked up Fiddler to watch what was going on, the problem went away.
Do you have suggestions to resolve this? I can't think of anything other than something really ugly like writing the file to the server and returning a page with a link to open the file directly.
Based on this question I think I am hosed.
There's some changes to the way IE8 handles persistance cookies which could be the route of your problems. There's an interesting post here that describes a possible solution.
The solution took us quite a while to find online believe it or not,
and when we found it we wanted to kick ourselves for not finding it
sooner. It all stems from the domain attribute of the forms
authentication settings within the web.config file of your
application. We typically left that attribute blank in our apps to
make it easier to develop. Further, none of the other browsers above
cared about that setting and functioned just fine. However, that
changed in IE8 and now that attribute is required.
I've been struggling with this for quite awhile and haven't been able to
find a solution. I need a user to be able to view multiple top level
domains with a single login.
My understanding is that this needs to be set in environment.rb and
called with before_dispatch. This is what I've come up with:
require 'activesupport'
require 'dispatcher'
module ActionController
class Dispatcher
def set_session_domain
ActionController::Base.session_options.update :session_domain => "#{#request.host}"
end
before_dispatch :set_session_domain
end
end
However, this does not seem to be working when I try and pull the values
from session[:session_domain].
Any help is greatly appreciated.
This one is a bit tricky. Since cookies can only be assigned to (and retrieved from) the current domain ("forms.example.com", say) and parent domains (".example.com", but not ".com"), but NOT to other domains ("othersite.com"), you'll have to find yourself another solution. This has nothing to do with Rails, but with how cookies work.
EDIT: Sessions rely on a client-specific handle, stored in a cookie, which is why sessions also don't work cross-domain.
This site has one possible solution for creating a cross-domain cookie, and it's the cleanest way I know of, although it may have some security implications. A more complicated version would have the servers communicate directly through some secure channel.
If you're looking for a more general-purpose single-login service, try implementing some form of OpenID.
For sub-domains in Rails 2.3
ActionController::Base.session = { :domain => ".mydomain.com" }
For top-level domains try this middleware.
I've been playing with the above middleware at the moment and it does not quite work as expected. If you do use the middleware you do not need the above code as it handles sub-domains as well.
You will probably need something like RubyCAS if you want authentication across domains regardless of whether they're top-level or subdomains.
Your question is not really precise enough IMHO. Do you want a single cookie for all Rails apps you have or is it within the context of a single one? If the former, you want to look at solutions using database-backed sessions or something along the line of RubyCAS to implement the CAS protocol.
Both Keltia and zuk are right, Answer is rubyCAS, We have do that integration and it allows
SSI - Single sign -in
You sign to one site and you are automatically signed to the other
SSO - Single Sign Out
You sign out from one site and automatically you signed out from the other
For us this is a proven solution and not a hard one to implement
we are using it in
http://www.cabslk.com and www.ticketslk.com
cheers,
Sameera