My issue is about $_SERVER['HTTP_REFERER']. I can't get the value of http_referer on my server or may be due to Firefox. But I've also printed print_r($_SERVER); but still it doesn't provide me previous page's link.
This is directly from PHP.net
The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
I'm thinking it may be a firefox issue. What version are you using?
Related
I'm facing an issue in AEM6.1 were the users have an invalid login-token (due to having an expired session). They make a request to AEM author which then has an error because they are basically an anonymous user attempting to view a page. The access problem results in a 404. The ACS error page tries to handle it, but the error page like everything else on author is not readable to an anonymous user. So it has a Java exception, and the user is left with a white screen of death
The login-token cookies in the browser have no expiration. They appear to be configured to stick around until the session is closed by the users. I would like to set expiration on the login-token cookies.
I've research around but do not see how this is done. The aemstuff site http://www.aemstuff.com/#article964 points to "Apache Jackrabbit Oak TokenConfiguration" But this was already set to 43200000, and further changes do not effect the login cookie expiration as far as I can see.
My question for SO is; is there a way to set the login-token expiration on the cookie? It seems like a bug with "Apache Jackrabbit Oak TokenConfiguration" or is it?
Create Apache Jackrabbit Oak TokenConfiguration as a config node.
In case others face similar problems, here some of the things I learned about this
login-token expiration can be configured as suggested by disha. It is used on the backend only. I think its very typical for browser session cookies to not have an the expiry set.
The WSOD issue experienced may have been helped by adjusting this session timeout slightly less than the IDP timeout
I think it's very important to use Java 8 with AEM6.1 and perhaps other versions as well. When we upgraded from AEM6, Java 7 remained our running version. Possibly the SAML SSO uses Java 8 things. After going to Java 8, users never had the WSOD again.
Post LinkedIn changes (around May 2015) have disabled our use of the share feature, via API call using the URL http://api.linkedin.com/v1/people/~/shares?format=json. We are now receiving a "403 authorization failed".
Steps taken to rehabilitate our share function:
Confirmed that ClientId & Client Secret keys are still the same as being used in our app
The Default Application Permissions have been confirmed, w_share is selected...which used to be rw_share (no longer available). Other selections made are r_basicprofile, r_emailaddress, & rw_company_admin...which are seemingly not related.
Authorized Redirect URLs are still applied for the domain we are using our application under.
Content type has been set to "application/xml", as suggested by other postings.
We have tried for months...hoping that any post changes to LinkedIn would have resolved our problem, yet nothing we have researched has helped. We figure that this might be a glitch from the permission modification update done by LinkedIn...since our code has never change, yet has worked for 2+ years prior to the May 2015 changes.
We would appreciate any insight as to what is going on here....as we are continuing to have this problem.
I found the problem, it was because the security of Linkedin changed. We had to had to alter the statement:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
to this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;
If you are relying on the "default application permissions", you may also want to double check that your OAuth code is not still requesting the old (no longer available) member permissions (e.g. rw_nus) via the ?scope= URL parameter, which will trump the "default application permissions" settings you've defined in your LinkedIn app's config.
Otherwise, the w_share permission should still be providing you the ability to post a share to LinkedIn.
I have an azure web site that I don't update anymore.
So I edited the web.config and added a rule to redirect to a new URL.
I made a type when typing the new URL and set the redirect mode to permanent.
No matter what I do, now I can not correct it because it seems it's permanently stuck this way.
The old URL now tries to redirect to some random incorrect typo location.
Is there a way to reverse this?
This sounds like it may be a local issue. Your browser may have cached the 302 response. Have you tried using a different browser, or clearing your browser's cache?
Otherwise, have you restarted the web site through the Azure portal?
I have a GWT app to deploy to Tomcat on a Windows server, with the following requirements:
1- The app should work fully, whether the user is in the Windows domain or not;
2- If the user happens to be in the domain, the app should be able to identify the user in some manner. Presumably, this should be via getThreadLocalRequest().getRemoteUser(), but any other alternative is fine...
3- If the user happens to be in the domain, the app should be able to access the MS Exchange server in that domain, without requiring the user to enter their password.
I've scoured the web high and low for this, but unfortunately, it seems there's no way to get authentication without forcing authentication. There are many examples of exclusions for, say, a login form or other "public" resources, but that won't work for us, since all the resources in a GWT app are packed into the same "page".
Maybe it's my limited understanding that's making me fail in some basic way, but I've tried to look at JCIFS, Jespa, Waffle and SPNEGO, and I just can't seem to get working the way I want to...
Any help would be greatly appreciated.
Cheers,
J.
How about putting a Javascript on your front page and have a Kerberos/SPNEGO protected page. The javascript will attempt to request a protected page, if the user is on the domain you will get the correct result from the page otherwise you will get 401 access denied. In the former case you can redirect your browser to exchange page, or have another AJAX call to retrieve things from exchange server in the later case you either show a log-in form or a generic anonymous page.
What about using JNI to call the Win32Api function LogonUser?
By doing impersonation at the thread level you will have the NTLM token added to the current thread and you would be able to call exchange with no issues
I want to delete record of those peoples who have remove app from their application's list, to do this I have entered that URL where I make a code to delete record of active user from my database in de-authorize callback. But still I'm unable to de-authorize users from by db.
Edit: See Facebook Deauthorize Callback over HTTPS for what my original problem really was. Summary: Improper web server configuration on my part.
Original answer was:
One potential problem has to do with https based deauthorize callbacks. At least some SSL certificates are not compatible with the Facebook back end servers that send the ping to the deauthorize callback. I was only able to process the data once I implemented a callback on an http based handler.
Some things to check...
That the URL of your server is visible from facebook's servers (ie not 192.168 or 10.0 unless you've got proper firewall and dns config).
Try using an anonymous surfing service and browsing to the URL you gave facebook - do you see a PHP Error?
Increase the loglevel for PHP and Apache/IIS to maximum and see if you get any more information
We can't do much more unless you give us your code...