I have two servers, the servers are the same windows version.
When I do this call
https://10.197.68.32/portaleclientiapi/odata/v1/ticket('FINLU%235R000239')?$expand=attachments&$select=attachments
the reply is this
{
"#odata.context":"https://10.197.68.32/mpssapi/odata/v1/$metadata#ticket(attachments)/$entity","attachments":[
]
}
but when I call the second server the answer is this
{
"#odata.context":"https://10.197.68.33/portaleclientiapi/odata/v1/$metadata#ticket(attachments)/$entity"
}
the call is exactly the same, but change only the ip address
10.197.68.32 or 10.197.68.33
can someone tell me where is the problem?
Both server have the same published website, I tried to copy files from the running ok server to the running bad server
Thanks
put [EnableQuery] on the action or put [AutoExpand] on the property Attachment in the model
Related
I have a MVC 6 application which is hosted in Azure as web app. It is running fine on local by iisexpress but when I hosted it in Azure using publish option in Visual Studio, it is not working. It is just waiting to load website. After 4-5 minutes wait, it displays nothing.
I also tested it with static file. I uploaded a static html file in wwwroot folder but it is also not working.
I am not getting how can I see the actual error. Anybody can help me?
Since you've provided almost no information I gonna have to guess, since I had a similar error this weekend when deploying an ASP.NET Core 1.0 WebApp to an Azure App Service.
The issue I was facing was, that the main application wouldn't start. After a couple of hours trying to figure it out I got an error message with the method mentioned in the comments (running web.cmd manually) which returned an Microsoft.AspNet.Server.Kestrel.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported exception.
I couldn't find anything directly related to it, but was a hint about an IPv6 problem. A few other SO posts hinted that setting http://*:12345 as port binds to both, IPv4 and IPv6. So after I changed the url to http://0.0.0.0:12345 in the hosting.json, it started without issues.
I filled an issue on Kestrel GitHub and this seems to be a bug in Kestrel.
Edit: In response to the comment:
I used to have
{
"server": "Microsoft.AspNet.Server.Kestrel",
"server.urls": "http://*:8081"
}
and changed it to
{
"server": "Microsoft.AspNet.Server.Kestrel",
"server.urls": "http://0.0.0.0:8081"
}
The difference seems to be that http://*:8081 also binds to both IPv4 and IPv6 on the same port, whereas http://0.0.0.0:8081 only binds on IPv4 and not on IPv6.
I am trying show end users maintainence window such as "we are down please try later" and disable the application but my problem is what if my worklight server itself is down and not reachable and i cannot use the feature provided by worklight console,
Is there a way i make my app talk to a different server which returns back the below json data when a app is disabled , can i simulate this behaviour is this possible.
json recieved on access disabled in worklight :-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
I have some conceptual problems with this question.
Typically a production environment (simplified) would not consist of a single server serving your end-users... meaning, there would be a cluster of nodes, each node being a Worklight Server, and this cluster would be behind a load balancer that would direct the incoming requests. And so in a situation where a node is down for maintenance like in your scenario there would still be more servers able to serve - there would be no down time.
And thus at this point your suggestion to simulate a Remote Disable by sending it from another(?) Worklight Server seems not so much the correct path to take (it may even be simply wrong). Have you had this second Worklight Server, why wouldn't it just serve the apps business like usual? See again my first paragraph about clustering.
Now lets assume there is still a downtime, that affects all servers. The application's client logic should be able to handle failed connections to the Worklight Server. In such a case you should handle this in the WL.Client.connect()'s onFailure callback function to display a WL.SimpleDialog that looks just like a Remote Disable's dialog... or perhaps via the initOption.js's onConnectionFailure callback.
Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.
Additionally though, perhaps a way to better handle maintenance mode on your server is to have the HTTP server return a specific HTTP status code, check for this code and display a proper message based on the returned HTTP status code.
To check for this code in a simple example:
Note: the getStatus method is available starting MobileFirst Platform Foundation 7.0 (formerly "Worklight").
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}
I am looking for some guidance on setting up an MVC/XSockets project on our servers running Windows Server 2003, R2 with IIS6.
Our team is developing a webapp that uses XSockets 3.x to dynamically display data in real time. We are using our time entry system to show current time entries on a "dashboard." Employees enter their times via a separate app, and the dashboard app is supposed to show most recent activity updates.
The project is made using the MVC4 framework. This works great when testing from my development machine, separate from the server. The ws server instance is setup on ws://x.x.x.x:4502, where x.x.x.x is the server's IP. The XSockets components are integrated in the same project.
After pushing my local project onto the server and doing some setup, everything works okay except the XSockets functionality. The XSockets server cannot be accessed from outside the server. When I test from within the server, meaning opening up a browser and going to the webapp, it works fine as it does on my dev machine.
I have tried following the custom configuration setup outlined on xsockets.net, but I am a little confused as to how to define the ws server instance. Do I use the server's IP? The localhost IP (127.0.0.1)? I tried both, but it won't work. I tried adding this custom config settings:
public class XSocketsConfig : ConfigurationSetting
{
public XSocketsConfig() : base(new Uri("ws://dashboard.ourdomain.com:4502/"), new Uri("ws://x.x.x.x:4502")) { }
}
From javascript I access the XSocket through the "ws://dashboard.ourdomain.com:4502/" connection, but it didn't work when I tested it after deploying to the server. I also tried:
public class XSocketsConfig : ConfigurationSetting
{
public XSocketsConfig() : base(new Uri("ws://x.x.x.x:4502")) { }
}
or
public class XSocketsConfig : ConfigurationSetting
{
public XSocketsConfig() : base(new Uri("ws://127.0.0.1:4502")) { }
}
I did enable the server firewall to let traffic through port 4502. Again, everything works great on my local machine, so this leaves me to believe it is either a setting on the server, or a config setting for XSockets.
What is the proper way of achieving a client-server connection on IIS 6? Pointers and suggestions are greatly appreciated as my several-day search has yielded no effective results yet.
Okay so I have finally figured it out. It was after all a firewall issue. I had to configure the firewall to allow traffic on the public ip and port and to forward that traffic to the private ip and port. My XSockets configuration ended up looking like this:
//http://xsockets.net/docs/configuration#public--private-endpoint
public class XSocketsConfig : ConfigurationSetting
{
public XSocketsConfig() : base(new Uri("ws://x.x.x.x:4502/"), new Uri("ws://y.y.y.y:4502")) { }
}
Where x.x.x.x is the server's public IP address and y.y.y.y the private IP address on the LAN. On the client side (js) I then do:
var conn = new XSockets.WebSocket('ws://x.x.x.x:4502/Activity');
That took a serious amount of troubleshooting but I am glad I got it figured out.
My Kohana app runs perfectly on my local machine.
When I deployed my app to a server (and adjust the config files appropriately), I can no longer log into the app.
I've traced through the app login routine on both my local version and the server version and they both agree with each other all the way through until you get to the auth.php controller logged_in() routine where suddenly, at line 140 - the is_object($this->user) test - the $user object no longer exists!?!?!?
The login() function call that calls the logged_in() function successfully passes the following test, which causes a redirect to the logged_in() function.
if(Auth::instance()->login($user, $post['password']))
Yes, the password and hash, etc all work perfectly.
Here is the offending code:
public function logged_in()
{
if ( ! is_object($this->user))
{
// No user is currently logged in
url::redirect('auth/login');
}
etc...
}
As the code is the same between my local installation and the server, I reckon it must be some server setting that is messing with me.
FYI: All the rest of the code works because I have a temporary backdoor available that allows me to use the application (view pages of tables, etc) without being logged in.
Any ideas?
I solved the problem (DUH!).
The answer was that the cookie.php config file had $config['domain'] = 'localhost'. Setting this to the actual domain that the app is installed in magically made my life happy again!
Thanks everyone for your help and interest.
We have a customer in the field that installed our client app on a new machine. When they try and login; which calls a WCF web service; they get the following error:
System.ServiceModel.CommunicationObjectAbortedException
"The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it has been Aborted."
They installed on another machine, and had no problem. The app is installed at several locations with no problems.
Any idea why it does not work on a single machine? The machine is running Windows 7, but the app is running on other machines with Windows 7.
Any ideas would be appreciated.
How are you making your calls to the service?
From what you've said it sounds a bit like the service call is failing and somehow you are trying to make a method call on the object that implements IChannel, i.e., it's in a using block and the dispose method is blowing up.
Post some code?
Here is the code:
try {
userService = Services.UserServiceClient();
LoggedInUser.User = userService.Login(tbUsername.Text, tbPassword.Text);
userService.Close();
}
catch... { }
But, like I said above, it is working on several other computers with no problems. Just not working on a single computer. Was thinking maybe some .net lib needs installed or something.